From isis-wg-admin@external.juniper.net Wed Mar 8 04:15: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 EAA22498 for ; Wed, 8 Mar 2000 04:15:37 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id BAA35388; Wed, 8 Mar 2000 01:17:02 -0800 (PST) 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 BAA35359 for ; Wed, 8 Mar 2000 01:17:00 -0800 (PST) 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 BAA07698 for ; Wed, 8 Mar 2000 01:11:43 -0800 (PST) Received: from jaws.cisco.com (jaws.cisco.com [198.135.0.150]) by rojo.juniper.net (8.9.3/8.9.3) with ESMTP id BAA46706 for ; Wed, 8 Mar 2000 01:26:15 -0800 (PST) (envelope-from mshand@cisco.com) Received: from mshand-8kcdt (lon-sto4-lan-vlan133-dhcp43.cisco.com [144.254.108.110]) by jaws.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id JAA26677 for ; Wed, 8 Mar 2000 09:11:38 GMT Message-Id: <4.2.2.20000308085433.00a85240@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 08 Mar 2000 09:12:03 +0000 To: isis-wg@juniper.net From: Mike Shand Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Isis-wg] Re: I-D ACTION:draft-ietf-isis-wg-mesh-group-00.txt 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:32 02/03/2000 -0500, Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts >directories. >This draft is a work item of the IS-IS for IP Internets Working Group of >the IETF. > > Title : IS-IS Mesh Groups > Author(s) : R. Balay, D. Katz, J. Parker > Filename : draft-ietf-isis-wg-mesh-group-00.txt > Pages : 9 > Date : 01-Mar-00 Just a few comments. In the modified 7.3.15.1. e.1.ii) there is no mention of what to do if the incoming circuit is 'meshblocked'. I assume this is do nothing, since if things are correctly configured you wouldn't receive an LSP over such a circuit, but the spec should be clear on this point. It could do with an example of how one is supposed to deploy it. It might be helpful to say that a very good way of shooting yourself in the foot is to define some links as meshSet and some links as meshBlocked in the same 'mesh'. One could argue that use of CSNPs gets you out of the hole, but maybe that is even worse because although you get the LSPs delivered eventually you introduce a considerable propagation delay. Oh and I think there's a typo. In the sentence leading up to the changes to section 7.3.15.3 clause b) (bottom of page 4) it says "...links with a mesh group meshEnabled or meshBlocked." presumably this should read "... links with a meshEnabled value of meshSet or meshBlocked" 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 Mar 8 04:33:33 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 EAA27896 for ; Wed, 8 Mar 2000 04:33:33 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id BAA35464; Wed, 8 Mar 2000 01:35:53 -0800 (PST) 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 BAA35433 for ; Wed, 8 Mar 2000 01:35:51 -0800 (PST) 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 BAA08522 for ; Wed, 8 Mar 2000 01:30:34 -0800 (PST) Received: from jaws.cisco.com (jaws.cisco.com [198.135.0.150]) by rojo.juniper.net (8.9.3/8.9.3) with ESMTP id BAA46915 for ; Wed, 8 Mar 2000 01:45:06 -0800 (PST) (envelope-from mshand@cisco.com) Received: from mshand-8kcdt (lon-sto4-lan-vlan133-dhcp43.cisco.com [144.254.108.110]) by jaws.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id JAA27186 for ; Wed, 8 Mar 2000 09:30:30 GMT Message-Id: <4.2.2.20000308092229.00aaa4a0@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 08 Mar 2000 09:30:55 +0000 To: isis-wg@juniper.net From: Mike Shand Subject: Re: [Isis-wg] Re: I-D ACTION:draft-ietf-isis-wg-mesh-group-00.txt In-Reply-To: <4.2.2.20000308085433.00a85240@jaws.cisco.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 09:12 08/03/2000 +0000, Mike Shand wrote: >In the modified 7.3.15.1. e.1.ii) there is no mention of what to do if the >incoming circuit is 'meshblocked'. I assume this is do nothing, since if >things are correctly configured you wouldn't receive an LSP over such a >circuit, but the spec should be clear on this point. Hmmm. Thinking about this some more, its not so obvious. If you received a CSNP over a meshBlocked circuit, and you had a newer LSP you would send it out over the meshBlocked circuit (since the draft makes no changes to section 7.3.15.2 c). Hence it would be entirely reasonable to receive an LSP over a circuit marked meshBlocked, even in a correctly configured network. So presumably one would want to accept that LSP and treat it as for meshSet? 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 Mar 8 10:32: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 KAA20177 for ; Wed, 8 Mar 2000 10:32:38 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA35939; Wed, 8 Mar 2000 07:33:47 -0800 (PST) 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 HAA35908 for ; Wed, 8 Mar 2000 07:33:45 -0800 (PST) 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 HAA26176 for ; Wed, 8 Mar 2000 07:28:26 -0800 (PST) Received: from redbaron.nexabit.com (d28.nexabit.com [209.6.34.253]) by rojo.juniper.net (8.9.3/8.9.3) with ESMTP id HAA50235 for ; Wed, 8 Mar 2000 07:43:01 -0800 (PST) (envelope-from jparker@nexabit.com) 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 KAA23937; Wed, 8 Mar 2000 10:28:22 -0500 Received: by bandito.nexabit.com with Internet Mail Service (5.5.2650.21) id ; Wed, 8 Mar 2000 10:28:22 -0500 Message-ID: From: Jeff Parker To: Mike Shand Cc: isis-wg@juniper.net Subject: RE: [Isis-wg] Re: I-D ACTION:draft-ietf-isis-wg-mesh-group-00.txt Date: Wed, 8 Mar 2000 10:28:20 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" 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:32 02/03/2000 -0500, Internet-Drafts@ietf.org wrote: > > > > Title : IS-IS Mesh Groups > > Author(s) : R. Balay, D. Katz, J. Parker > > Filename : draft-ietf-isis-wg-mesh-group-00.txt > > Pages : 9 > > Date : 01-Mar-00 > > Just a few comments. Mike - Thanks for your careful reading. > In the modified 7.3.15.1. e.1.ii) there is no mention of what > to do if the incoming circuit is 'meshblocked'. I assume this > is do nothing, since if things are correctly configured you > wouldn't receive an LSP over such a circuit, but the spec > should be clear on this point. I would imagine that this would be a legal configuration, and that some might find a use for one way links like this. > It could do with an example of how one is supposed to deploy it. I suppose documenting them is one step on the slippery slope to advocating them. Perhaps I can find some weasel words and add an example: maybe a 6-way complete mesh constrained to have a couple of alternative flooding paths between each pair. > It might be helpful to say that a very good way of shooting > yourself in the foot is to define some links as meshSet and > some links as meshBlocked in the same 'mesh'. One could argue > that use of CSNPs gets you out of the hole, but maybe that is > even worse because although you get the LSPs delivered > eventually you introduce a considerable propagation delay. > > Oh and I think there's a typo. In the sentence leading up to > the changes to > section 7.3.15.3 clause b) (bottom of page 4) it says > > "...links with a mesh group meshEnabled or meshBlocked." > > presumably this should read > "... links with a meshEnabled value of meshSet or meshBlocked" > > Mike Thanks - will make that edit. - jeff parker - jdparker@lucent.com _______________________________________________ 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 Mar 8 11:01:30 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 LAA00955 for ; Wed, 8 Mar 2000 11:01:27 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA36031; Wed, 8 Mar 2000 08:03:20 -0800 (PST) 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 IAA36003 for ; Wed, 8 Mar 2000 08:03:19 -0800 (PST) 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 HAA27944 for ; Wed, 8 Mar 2000 07:58:00 -0800 (PST) Received: from redbaron.nexabit.com (d28.nexabit.com [209.6.34.253]) by rojo.juniper.net (8.9.3/8.9.3) with ESMTP id IAA50793 for ; Wed, 8 Mar 2000 08:12:34 -0800 (PST) (envelope-from jparker@nexabit.com) 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 KAA24193; Wed, 8 Mar 2000 10:57:56 -0500 Received: by bandito.nexabit.com with Internet Mail Service (5.5.2650.21) id ; Wed, 8 Mar 2000 10:57:55 -0500 Message-ID: From: Jeff Parker To: Mike Shand Cc: isis-wg@juniper.net Subject: RE: [Isis-wg] Re: I-D ACTION:draft-ietf-isis-wg-mesh-group-00.txt Date: Wed, 8 Mar 2000 10:57:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" 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 > >In the modified 7.3.15.1. e.1.ii) there is no mention of > >what to do if the incoming circuit is 'meshblocked'. > > Hmmm. Thinking about this some more, its not so obvious. If > you received a CSNP over a meshBlocked circuit, and you had > a newer LSP you would send it out over the meshBlocked circuit > (since the draft makes no changes to section 7.3.15.2 c). > Hence it would be entirely reasonable to receive an LSP over > a circuit marked meshBlocked, even in a correctly configured > network. So presumably one would want to accept that LSP and > treat it as for meshSet? > > Mike Sorry, missed this when replying to previous. Is there a reason to discard any valid LSP? We do solicit them when we detect a missing LSP listed in a CSNP. We could check to see if this one arrived "on it's own" or if we asked for it, but this seems excessive. I see Mesh Groups as a way to cut back on transmissions. Once the network has taken the trouble to deliver an LSP, taking the time to check to see if the LSP is new, and keeping it if it is, seems conservative. - jdparker@lucent.com - Lucent INS _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Sun Mar 12 02:38:20 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 CAA23660 for ; Sun, 12 Mar 2000 02:38:19 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id XAA42429; Sat, 11 Mar 2000 23:40:19 -0800 (PST) Received: from fsnt.future.futusoft.com ([203.197.140.35]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id XAA42401 for ; Sat, 11 Mar 2000 23:40:13 -0800 (PST) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futusoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Sun, 12 Mar 2000 13:13:29 +0530 Received: from selvarajr ([172.16.1.27]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id MAA12003 for ; Sun, 12 Mar 2000 12:52:54 +0530 Received: by localhost with Microsoft MAPI; Sun, 12 Mar 2000 13:03:03 +0530 Message-Id: <01BF8C23.4CEE68A0.selvarajr@future.futsoft.com> From: SelvarajR To: "'ISIS-WG'" Date: Sun, 12 Mar 2000 13:02:59 +0530 X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="---- =_NextPart_000_01BF8C23.4D49F620" Subject: [Isis-wg] Doubt regarding DR election 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_01BF8C23.4D49F620 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, Regarding DR election 10589 : 92 section 8.4.5 (e) states that DR election process can start whenever an IIH PDU is received or transmitted as described in 8.4.4. I find this little bit vague. To my understanding I find it is better to start the DR election whenever 1. A new IIH PDU with higher priority than the existing DR been received. 2. The priority of any existing neighbour been increased higher than the existing DR 3. Initially after waiting for twice the Hello interval when circuit comes UP The third point is mentioned clearly . But the remaining cases are vague if I go through the STD. Will it happen to conduct DR election during transmission of IIH at any time. Some clarification with points of cases will be helpful. Thanx Selva ------ =_NextPart_000_01BF8C23.4D49F620 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IgMHAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEkAYAqAEAAAEAAAAQAAAAAwAAMAIAAAAL AA8OAAAAAAIB/w8BAAAAbgAAAAAAAAC1O8LALHcQGqG8CAArKlbCFQAAABPeZmteYdMRqFgAIDUf kqBkiAAAAAAAAIErH6S+oxAZnW4A3QEPVAIAAAAASVNJUy1XRwBTTVRQAGlzaXMtd2dAZXh0ZXJu YWwuanVuaXBlci5uZXQAAAAeAAIwAQAAAAUAAABTTVRQAAAAAB4AAzABAAAAHQAAAGlzaXMtd2dA ZXh0ZXJuYWwuanVuaXBlci5uZXQAAAAAAwAVDAEAAAADAP4PBgAAAB4AATABAAAACgAAACdJU0lT LVdHJwAAAAIBCzABAAAAIgAAAFNNVFA6SVNJUy1XR0BFWFRFUk5BTC5KVU5JUEVSLk5FVAAAAAMA ADkAAAAACwBAOgEAAAAeAPZfAQAAAAgAAABJU0lTLVdHAAIB918BAAAALAAAAL8AAAC1O8LALHcQ GqG8CAArKlbCFQAAABPeZmteYdMRqFgAIDUfkqBkiAAAAwD9XwEAAAADAP9fAAAAAAIB9g8BAAAA BAAAAAAAAALsVAEEgAEAHAAAAERvdWJ0IHJlZ2FyZGluZyBEUiBlbGVjdGlvbgD6CQEFgAMADgAA ANAHAwAMAA0AAgA7AAAAMAEBIIADAA4AAADQBwMADAAMAB4AKAAAADgBAQmAAQAhAAAARjYzQTAx RTIwNkY4RDMxMUE4NTgwMDIwMzUxRjkyQTAA6AYBA5AGANAKAAAgAAAACwACAAEAAAALACMAAAAA AAMAJgAAAAAACwApAAAAAAADADYAAAAAAEAAOQBgoj4x9Yu/AR4AcAABAAAAHAAAAERvdWJ0IHJl Z2FyZGluZyBEUiBlbGVjdGlvbgACAXEAAQAAABYAAAABv4v1MS3iATsW+AYR06hYACA1H5KgAAAe AB4MAQAAAAUAAABTTVRQAAAAAB4AHwwBAAAAHQAAAHNlbHZhcmFqckBmdXR1cmUuZnV0c29mdC5j b20AAAAAAwAGEMz20FMDAAcQXQIAAB4ACBABAAAAZQAAAEhJLFJFR0FSRElOR0RSRUxFQ1RJT04x MDU4OTo5MlNFQ1RJT044NDUoRSlTVEFURVNUSEFURFJFTEVDVElPTlBST0NFU1NDQU5TVEFSVFdI RU5FVkVSQU5JSUhQRFVJU1JFQ0UAAAAAAgEJEAEAAACuBwAAqgcAADgRAABMWkZ1nCKJTgMACgBy Y3BnMTI1cjIMYGMxAzABBwtgbpEOEDAzMw8WZmUPkk8B9wKkA2MCAGNoCsBzhGV0AtFwcnEyAACS Kgqhbm8SUCAwAdCFAdA2D6AwNTA0FCHzAdAUEDR9B20CgwBQA9T7Ef8TC2IT4RRQE7IY9BTQrwcT AoACkQjmOwlvMBrf+mUOMDUcCh0hHN8d6Rv0/x4SHH8gTyANH48dvxwPEGD8Mjgl2ibxJq8nuRv0 J+K/Jk8qHyndKV8njytUOQ5QHy6kMAEoIzAAAoJzdHlqbAeQaAngdAAAA/BkGGN0bAqxAGBkanVz MXAFEGdoBUIWMgwBY4cJwDJAAzBzbmV4FzAvB7AFsADAAnNzAFBzYpYyFFAxYGET8FxrCeC+cAuQ MjgIYDJwC4BlMaD+djfgAUAy2wwwM6QoADaAmwSgC4BnJ/E0JmJhFxB+ZAIgNOA0hjHQMtA6ESD+ MTEzDlA13zbvN/MAUTh8/wCgM646/zwGMSQPwD0PPh+/N/MOUDhvQM9B3zwzMwKCPRMQYzWgSKEy 0DwwdGmJOBAgRAEQYXVsBUAKUArAYQnAYXBoII5GAiE1ZCVAZmktD5BeOAFAN7BNMzI4Ygsgcs8J UE6SFqBOknc0JUEXAP5wAdBKcjL/R59IpkzQS5AbBRACMC1MMANhOiBUQm9T8FN1YmoFkHRBU/BE YXRlOjVkNv9M/04PTx9QLjHAPCMOIUihbzk2DlBRr1K+UjgBFwEg7kg8EQSQNWQ3Va9Wv1fPv0ih N49ZPw+QZDAI0GIKsPx0OEb6D1RD0Fs/XEZkwPNdUAtQeS9MQFgwCxFdxf5zNWQoAF6/X89g31A/ UU/fZt9n6lQSU7RU6TkyL21FHWRzOW2fbq9z4ERvY/51B4ACMAXQTAAaAxMQYjA/MXABkTGgAAB3 YndUZW0/C1FVAHIwAdAv8FWANDP/AFB3YgCQeMF35WJzagBigm5uFsBp8WKCanu2AhBs/QkAd3vF MXAKwAGQUwB9Nf0KsGMKYHs0C4ABAAIwAeFnYnNVADTAXCcToIBRMO4uAoJ7RHZgYl2BgFE8gf1p gjNEMWIwgoJ8MHdlDMFNgoEggPJ3cW5hB4Agv4Ihd2J5IQ+QeaABwDgwAP13CG9dcTRBFyB3uIa2 hQ/7hmsFoHV/cWoANaAaEHIS730AclBrUQGAblRwAGAJ8P9KoHZAAgE1IFnSiFCMUTGAknAegFx2 CJB3a38x/2YAjcIE8AdAEGEBQA4AayL3PAKPJQIQbwVCFyES8nimoCBDOlxcU0BvS+HebUwwAxAH kJHQTQ3gA2Dkc28BgCBPASAN4IhQWlyThkUAwAMQLkhwdN+CMBcQclA0YWIyeAFAjCG+bjHQGvCV JEs0gzAgEvPzAIAFkGx2P2FEkA5wNSD/l7J9ophCfzQBwZexFuAPcM8AAESQDNABkCAudwSXxv8O UJhiS3AysJjfme+a/w/A30SQBYGcn52vnr9sZgBEkO5snF+hH6IlKZssJUCf/+Ok36IUYiAoApGl /5fz/1WQo6+ob6l/qo+YIF6Qq9L/mK+tP65PmywoAKvfsV+yb/+zf5ggcgCwX7Xvtv+4BAr5DwMw ci9tXzRRe0hpLBsKhV1QZwsRPEJEUiDrYmG90GkCICA8cBQgheA2IFPwMAAglTLBwjguxDQuUyAo ZSnCsH3R/QeRdBbgBUDBShdwdkAHkM8EII6wA6B9kyB3MdA0oEVdcSADkUlJSEuQRPRVIAQAIBrw fqBK4TRg9wWxvpAAcW1KwFUANGBIQP4gAQAE8oGgNGC9YcNCw2D9xzAgaZB/QMRBx8FiMAJAyTGg IGJKwCB2S9AKUMPKwFQQIG15IIpgaNL/AZB/QDxCyuXMIcfBgaB4kf/IkczQxiTEUEsBwVnGhwqF /6IDgCILCjO8y2AW0ABgAEH8ZGLUI2nxdkDUMABAPHD+LgyCvLUDMYJqvaiDLZeEzwrhtNCYIAbg ZHkMQJgR/4qTl7EEoJBgpVKnn39SgoKPoa+E8TWhvkp7QSA0oP8H4MdGA/DEUDvwvrHG4Rdw/8HA BRAxgMRCA6DP0jSwhSLvwRSBoAnwx+cu0W/Sf9OP/dSfMtW/1s/X39jv2f/bD/fcH90v3j1Uz+Hg x5NAxwH/zQDh5zSgvrEG4Ahw4pQLgP8FADwQSFHgRuFfwTHjj+Sf++Wv5r8z59/o7+n/6w/sH+/t L+4/70/ePUkBIErQB0D/Z/DHAIuwxuFoUErBPFGMkf/EQBZwfqDPw13QfOHKMc8Bz8xQl2DGgsXQ aXJ2UMwh84pAFRJVUAqF+wa9r97Ez/ZV8ULLUWhxcG9TYcey/3ZywcHIUYMwPBBrUASQysD+QmIQ z8Ma8JSROgLF0RNwf86w9pATgMxTx7DyIMrgZzfM0OAgkxB180DPw1NUekTKwFeUsJdgzCEW4HD/ jYD1QczQikB/QJiAxIwS8P9TUTxgyLXFsMHC8hHHQsRx3/JCStCEsON29lVTCEENQf/2kBAQkvBU 8NCT4BIMI86wf/IRDxTgABHBgaA78QnwZu9LYON28UDI0HjRVhZ8CS/33kxHAvhANFRAYmDMUIDw CRyGfQAgcAAAAwAQEAAAAAADABEQAAAAAAMAgBD/////QAAHMCDEha3wi78BQAAIMCDEha3wi78B CwAAgAggBgAAAAAAwAAAAAAAAEYAAAAAA4UAAAAAAAADAAKACCAGAAAAAADAAAAAAAAARgAAAAAQ hQAAAAAAAAMABYAIIAYAAAAAAMAAAAAAAABGAAAAAFKFAADzFQAAAwAHgAggBgAAAAAAwAAAAAAA AEYAAAAAAYUAAAAAAAAeAAiACCAGAAAAAADAAAAAAAAARgAAAABUhQAAAQAAAAUAAAA4LjA0AAAA AAsACYAIIAYAAAAAAMAAAAAAAABGAAAAAA6FAAAAAAAAAwAKgAggBgAAAAAAwAAAAAAAAEYAAAAA EYUAAAAAAAADAAuACCAGAAAAAADAAAAAAAAARgAAAAAYhQAAAAAAAB4ADIAIIAYAAAAAAMAAAAAA AABGAAAAADaFAAABAAAAAQAAAAAAAAAeAA2ACCAGAAAAAADAAAAAAAAARgAAAAA3hQAAAQAAAAEA AAAAAAAAHgAOgAggBgAAAAAAwAAAAAAAAEYAAAAAOIUAAAEAAAABAAAAAAAAAB4APQABAAAAAQAA AAAAAAADAA00/TcAAP6c ------ =_NextPart_000_01BF8C23.4D49F620-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Sun Mar 12 17:23:26 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 RAA24885 for ; Sun, 12 Mar 2000 17:23:25 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA43278; Sun, 12 Mar 2000 14:23:46 -0800 (PST) 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 OAA43252 for ; Sun, 12 Mar 2000 14:23:43 -0800 (PST) Received: from mshand-8kcdt (mshand-isdn-home1.cisco.com [10.49.144.123]) by jaws.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id WAA07143; Sun, 12 Mar 2000 22:17:38 GMT Message-Id: <4.2.2.20000312221048.00aa0470@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Sun, 12 Mar 2000 22:13:48 +0000 To: SelvarajR , "'ISIS-WG'" From: Mike Shand Subject: Re: [Isis-wg] Doubt regarding DR election In-Reply-To: <01BF8C23.4CEE68A0.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 Well, since the standard specifies only externally visible behaviour it makes no difference. If you 'run' the DR election in a case where there is no change it is exactly equivalent to not running it. Whether you actually 'run' it or not is an implementation detail. You could regard some of your cases as actually running the election and then aborting it when you discover that the PDU is not a higher priority. etc. etc. Mike At 13:02 12/03/2000 +0530, SelvarajR wrote: >Hi, >Regarding DR election 10589 : 92 section 8.4.5 (e) states that DR election >process can start whenever an IIH PDU is received or transmitted as >described in 8.4.4. I find this little bit vague. To my understanding I >find it is better to start the DR election whenever >1. A new IIH PDU with higher priority than the existing DR been received. >2. The priority of any existing neighbour been increased higher than the >existing DR >3. Initially after waiting for twice the Hello interval when circuit comes >UP > >The third point is mentioned clearly . But the remaining cases are vague if >I go through the STD. Will it happen to conduct DR election during >transmission of IIH at any time. > >Some clarification with points of cases will be helpful. >Thanx > > >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 Fri Mar 17 07:43:16 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 HAA07673 for ; Fri, 17 Mar 2000 07:43:14 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id EAA56635; Fri, 17 Mar 2000 04:41:59 -0800 (PST) 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 EAA56603 for ; Fri, 17 Mar 2000 04:41:57 -0800 (PST) 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 EAA13388 for ; Fri, 17 Mar 2000 04:35:34 -0800 (PST) Received: from malmo.trab.se (malmo.trab.se [131.115.48.10]) by rojo.juniper.net (8.9.3/8.9.3) with ESMTP id EAA13623 for ; Fri, 17 Mar 2000 04:51:26 -0800 (PST) (envelope-from Henrik.J.Villfor@telia.se) Received: from trab-hermes.haninge.trab.se (trab-hermes.haninge.trab.se [131.115.158.15]) by malmo.trab.se (8.9.1/TRAB-primary-2) with ESMTP id NAA00355 for ; Fri, 17 Mar 2000 13:35:30 +0100 (MET) Received: by trab-hermes.haninge.trab.se with Internet Mail Service (5.5.2448.0) id ; Fri, 17 Mar 2000 13:35:28 +0100 Message-ID: <778DFE9B4E3BD111A74E08002BA3DC0D0185E22C@trab-hermes.haninge.trab.se> From: =?ISO-8859-1?Q?Henrik_Villf=F6r?= To: isis-wg@juniper.net Date: Fri, 17 Mar 2000 13:35:27 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" Subject: [Isis-wg] BGP in L1 routers 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. Reading I am a bit surprised to find the following. " When a router learns multiple possible paths to external destinations via BGP, it will select only one of those routes to be installed in the forwarding table. One of the factors in the BGP route selection is the IGP cost to the BGP next hop address. Many ISP networks depend on this technique, which is known as "shortest exit routing". If a L1 router does not know the exact IGP metric to all BGP speakers in other L1 areas, it cannot do effective shortest exit routing. " What confuses me is that I was under the very strong impression that destinations could not be installed from BGP unless a route to the BGP next hop existed in the RIB and FIB and that a default route (as would be what is available in an L1 router for an external route) would not do. I would much appreciate if one of you wise people would spare the time to enlighten me. Thank's in advance, Henrik Villfor Telia Research _______________________________________________ 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 Mar 17 12:46:52 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 MAA08804 for ; Fri, 17 Mar 2000 12:46:50 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id JAA56990; Fri, 17 Mar 2000 09:50:09 -0800 (PST) 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 JAA56928 for ; Fri, 17 Mar 2000 09:50:06 -0800 (PST) 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 JAA03102 for ; Fri, 17 Mar 2000 09:43:41 -0800 (PST) Received: from tcb.net (tcb.net [205.168.100.1]) by rojo.juniper.net (8.9.3/8.9.3) with ESMTP id JAA18818 for ; Fri, 17 Mar 2000 09:59:36 -0800 (PST) (envelope-from danny@sofos.tcb.net) Received: from sofos.tcb.net (sofos.tcb.net [127.0.0.1]) by tcb.net (8.9.3/8.9.3) with ESMTP id KAA15295 for ; Fri, 17 Mar 2000 10:43:28 -0700 Message-Id: <200003171743.KAA15295@tcb.net> To: isis-wg@juniper.net From: Danny McPherson Reply-To: danny@tcb.net Subject: Re: [Isis-wg] BGP in L1 routers Date: Fri, 17 Mar 2000 10:43:28 -0700 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 Extracted from RFC 1771, Section 9.1.2: [...] If the NEXT_HOP attribute of a BGP route depicts an address to which the local BGP speaker doesn't have a route in its Loc-RIB, the BGP route SHOULD be excluded from the Phase 2 decision function. [...] The local speaker MUST determine the immediate next hop to the address depicted by the NEXT_HOP attribute of the selected route by performing a lookup in the IGP and selecting one of the possible paths in the IGP. This immediate next hop MUST be used when installing the selected route in the Loc-RIB. I see no reason why "one of the possible paths in the IGP" could not be the "default" route, so long as the immediate next hop address can be determined. -danny > " When a router learns multiple possible paths to external destinations > via BGP, it will select only one of those routes to be installed in > the forwarding table. One of the factors in the BGP route selection > is the IGP cost to the BGP next hop address. Many ISP networks > depend on this technique, which is known as "shortest exit routing". > If a L1 router does not know the exact IGP metric to all BGP speakers > in other L1 areas, it cannot do effective shortest exit routing. " > > What confuses me is that I was under the very strong impression that > destinations could not be installed from BGP unless a route to the BGP next > hop existed in the RIB and FIB and that a default route (as would be what is > available in an L1 router for an external route) would not do. _______________________________________________ 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 Mar 21 05:25:28 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 FAA09243 for ; Tue, 21 Mar 2000 05:25:26 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id CAA64220; Tue, 21 Mar 2000 02:25:10 -0800 (PST) Received: from btm4r4.alcatel.be (btm4r4.alcatel.be [195.207.101.110]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id CAA64189 for ; Tue, 21 Mar 2000 02:25:03 -0800 (PST) Received: from sh.bel.alcatel.be (btm04u.sh.bel.alcatel.be [138.203.194.104]) by btm4r4.alcatel.be (8.9.1a/8.9.1) with ESMTP id LAA29260 for ; Tue, 21 Mar 2000 11:18:09 +0100 (MET) Received: from sh.bel.alcatel.be (btmp6y [138.203.194.110]) by sh.bel.alcatel.be (8.7/8.7) with ESMTP id LAA09883; Tue, 21 Mar 2000 11:12:05 +0100 (MET) Message-ID: <38D74AF4.F5901558@sh.bel.alcatel.be> Date: Tue, 21 Mar 2000 11:12:05 +0100 From: Hans De Vleeschouwer WX29 58223 Organization: Alcatel Telecom X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.6 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: "isis-wg@external.juniper.net" CC: Steffen Brockmann , Ravindra Nara Content-Type: multipart/alternative; boundary="------------35B21A56A6ED8AD8BC1FBE0D" Subject: [Isis-wg] question related to isisSystemTable 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 --------------35B21A56A6ED8AD8BC1FBE0D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I have a question related to the isisSysTable On one hand we see that the table contains a row-status. This seems to indicate that the operator can create and delete rows. The question we have is: why are the objects not read-create in stead of read-write. Since non of the objects are read-create a row can in fact not be created by the operator (see RFC 2578). In our implementation we would allow only 1 instance of the protocol. Does it still make sense in this case, to allow the operator to create and delete this row, or would it make more sense to have always one row, and use the isisSysOperState to turn on/off the protocol. Any help is kindly appreciated. Kind regards, Hans De Vleeschouwer Alcatel --------------35B21A56A6ED8AD8BC1FBE0D Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi,

I have  a question related to the isisSysTable

On one hand we see that the table contains a row-status. This seems to indicate that the operator can create and delete rows.


The question we have is: why are the objects not read-create in stead of read-write. Since non of the objects are read-create a row can in fact not be created by the operator (see RFC 2578).

In our implementation we would allow only 1 instance of the protocol.  Does it still make sense in this case, to allow the operator to create and delete this row,  or would it make more sense to have always one row, and use the isisSysOperState to turn on/off the protocol.
 

Any help is kindly appreciated.
 

Kind regards,
    Hans De Vleeschouwer
    Alcatel --------------35B21A56A6ED8AD8BC1FBE0D-- _______________________________________________ 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 Mar 21 07:48:03 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 HAA25928 for ; Tue, 21 Mar 2000 07:48:02 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id EAA64418; Tue, 21 Mar 2000 04:47:55 -0800 (PST) Received: from fsnt.future.futusoft.com ([203.197.140.35]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id EAA64387 for ; Tue, 21 Mar 2000 04:47:49 -0800 (PST) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futusoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Tue, 21 Mar 2000 18:19:40 +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 RAA28703; Tue, 21 Mar 2000 17:58:03 +0530 Received: by localhost with Microsoft MAPI; Tue, 21 Mar 2000 17:58:08 +0530 Message-Id: <01BF935F.038FDFC0.navaneethk@future.futsoft.com> From: Navaneeth K Reply-To: "navaneethk@future.futsoft.com" To: "'isis-wg@external.juniper.net'" Date: Tue, 21 Mar 2000 17:58:03 +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 configuration 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 all.. My doubt is with regard to the configuration of Summary Addresses in ISIS . i. Can summary addresses be configured for both Level 1 and Level 2? If so , how do we use the Level 1 summary addresses? In advertising the summary addresses , do we take it from the Level 1 LSPs or from the routes calculated by Level 1 Decision process? ii. In the configuration of the summary address , there are two parts the address mask and the prefix mask. How are these used and what values do these take? Can anyone explain these with an illustration? Any help in this regard is most welcome. Thanks 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 Tue Mar 21 08:42: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 IAA13212 for ; Tue, 21 Mar 2000 08:42:49 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id FAA64541; Tue, 21 Mar 2000 05:43:41 -0800 (PST) Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id FAA64510 for ; Tue, 21 Mar 2000 05:43:39 -0800 (PST) Received: from zsc4c002.corpwest.baynetworks.com (actually h0295.s86b1.BayNetworks.COM) by smtprch1.nortel.com; Tue, 21 Mar 2000 07:34:51 -0600 Received: from zbl6c002.corpeast.baynetworks.com ([132.245.205.52]) by zsc4c002.corpwest.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id HA5B8BVD; Tue, 21 Mar 2000 05:34:31 -0800 Received: from nortelnetworks.com (CC775382-A [132.245.139.207]) by zbl6c002.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id GWL9DNXT; Tue, 21 Mar 2000 08:34:30 -0500 Message-ID: <38D77A31.B6268437@nortelnetworks.com> Date: Tue, 21 Mar 2000 08:33:37 -0500 X-Sybari-Space: 00000000 00000000 00000000 From: "Rajesh Saluja" Organization: Nortel Networks X-Mailer: Mozilla 4.5 [en]C-AtHome0402 (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: "navaneethk@future.futsoft.com" CC: "'isis-wg@external.juniper.net'" Subject: Re: [Isis-wg] Clarification on ISIS configuration References: <01BF935F.038FDFC0.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 Navaneeth K wrote: > > Hi all.. > > My doubt is with regard to the configuration of Summary Addresses in ISIS . > > i. Can summary addresses be configured for both Level 1 and Level 2? Only for Level2 as far as RFC is concerned. Summarization is done while advertising L1 routes into L2 domain. > If so , how do we use the Level 1 summary addresses? In advertising the summary addresses , > do we take it from the Level 1 LSPs or from the routes calculated by Level 1 Decision process? from the routes calculated by Level 1 decision process. > ii. In the configuration of the summary address , there are two parts the address mask and the prefix mask. > How are these used and what values do these take? Can anyone explain these with an illustration? If you have 192.9.3.0/24 and 192.9.2.0/24 networks allocated to your L1 domain, you could configure 192.9.2.0/23 as summary address which will basically aggregate both while advertising to L2 domain. Regards, Rajesh _______________________________________________ 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 Mar 21 13:17:59 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 NAA25086 for ; Tue, 21 Mar 2000 13:17:58 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA64782; Tue, 21 Mar 2000 10:14:06 -0800 (PST) Received: from kraak.procket.com (c187108056.telekabel.chello.nl [212.187.108.56]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA64753 for ; Tue, 21 Mar 2000 10:14:02 -0800 (PST) From: henk@procket.com Received: (from henk@localhost) by kraak.procket.com (8.9.3/8.9.3) id TAA04441; Tue, 21 Mar 2000 19:11:57 +0100 Message-Id: <200003211811.TAA04441@kraak.procket.com> Subject: Re: [Isis-wg] Clarification on ISIS configuration To: navaneethk@future.futsoft.com Date: Tue, 21 Mar 2000 19:11:57 +0100 (CET) Cc: isis-wg@external.juniper.net ('isis-wg@external.juniper.net') In-Reply-To: <01BF935F.038FDFC0.navaneethk@future.futsoft.com> from "Navaneeth K" at Mar 21, 2000 05:58:03 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 Hello Navaneeth, hello all, > My doubt is with regard to the configuration of Summary Addresses in ISIS . > > i. Can summary addresses be configured for both Level 1 and Level 2? Yes, they can now. RFC1195 only specifies L1->L2 leaking, and only specifies redistribution into L2. This has changed with the new draft draft-ietf-isis-domain-wide-02.txt. > If so , how do we use the Level 1 summary addresses? With the new draft about route-leaking, there are now two descriptions of how routes can be summarized into L1. 1) is via L2->L1 route-leaking, and 2) via redistribution from outside the IGP into ISIS. > In advertising the summary addresses , do we take it from the Level > 1 LSPs or from the routes calculated by Level 1 Decision process? From routes calculated. The rule of thumb for routing protocols is that you only advertise routes that you use yourself. So if a prefix is in the LSPDB, but for some reason you didn't install it in the RIB, then you will not advertise it. Nor use it when calculating summary addresses. 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 Mar 22 01:22: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 BAA04510 for ; Wed, 22 Mar 2000 01:22:13 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id WAA65408; Tue, 21 Mar 2000 22:23:40 -0800 (PST) Received: from fsnt.future.futusoft.com ([203.197.140.35]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id WAA65379 for ; Tue, 21 Mar 2000 22:23:19 -0800 (PST) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futusoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Wed, 22 Mar 2000 11:55:30 +0530 Received: from cairo.future.futsoft.com ([172.16.1.37]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id LAA03615 for ; Wed, 22 Mar 2000 11:36:49 +0530 Received: by localhost with Microsoft MAPI; Wed, 22 Mar 2000 11:50:38 +0530 Message-Id: <01BF93F4.D79A9A40.vanik@future.futsoft.com> From: "vanisri .k" Reply-To: "vanik@future.futsoft.com" To: "'isis-wg@external.juniper.net'" Date: Wed, 22 Mar 2000 11:50:37 +0530 Organization: Future Software X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 Subject: [Isis-wg] Reg. multiple IP addr and Advt of L1 Addr in L2 Lsps 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, I have doubts regarding the following. Please clarify me. 1. IS-IS allows multiple IP addresses assigned to an physical interface. What is the significant of it and where it is applied? 2. L2 Router advertises in its level 2 LSPs all the IP addresses reachable in their area. Summary address can be configured, otherwise all the level 1 Addresses obtained from the level 1 LSPs has to be advertised. My doubt is can we get the addresses from the "level 1 Forwarding Data base" instead of "level1 LSPs". RFC says (Sec 3.2 of 1195) these are determined from level 1 LSPs. Should the l2 router collects all l1 reachable addresses and the cost to reach them from level 1 LS data base, if summary address is not configured. Thanks -vani _______________________________________________ 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 Mar 22 09:43:51 2000 Received: from external.juniper.net ([208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11660 for ; Wed, 22 Mar 2000 09:43:51 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id GAA66015; Wed, 22 Mar 2000 06:41:55 -0800 (PST) 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 GAA65986 for ; Wed, 22 Mar 2000 06:41:53 -0800 (PST) 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 JAA09826; Wed, 22 Mar 2000 09:34:46 -0500 Received: by bandito.nexabit.com with Internet Mail Service (5.5.2650.21) id ; Wed, 22 Mar 2000 09:34:46 -0500 Message-ID: From: Jeff Parker To: vanik@future.futsoft.com, "'isis-wg@external.juniper.net'" Subject: RE: [Isis-wg] Reg. multiple IP addr and Advt of L1 Addr in L2 Lsp s Date: Wed, 22 Mar 2000 09:34:40 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" 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, > > I have doubts regarding the following. Please > clarify me. > > 1. > IS-IS allows multiple IP addresses assigned to > an physical interface. What is the significant of it > and where it is applied? IP allows multiple IP addresses assigned the the same interface. This can be used to allow a router to participate in multiple networks. ISIS just relays the information. > 2. > L2 Router advertises in its level 2 LSPs all the IP addresses > reachable in their area. Summary address can be configured, > otherwise all the level 1 Addresses obtained from the level 1 > LSPs has to be advertised. An optimization lets you reduce the network load by checking to see if the L1 route is comming from an L1/L2 router, which can be trusted to put it into L2 for you. > My doubt is can we get the addresses from the "level 1 > Forwarding Data base" > instead of "level1 LSPs". > RFC says (Sec 3.2 of 1195) these are determined from > level 1 LSPs. Should the l2 router collects all l1 reachable > addresses and the cost to reach them from level 1 LS data base, > if summary address is not configured. > > Thanks > -vani There are a number of issues in your question: I'm not sure which you are asking about. - jeff parker - Lucent INS _______________________________________________ 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 Mar 22 09:50:05 2000 Received: from external.juniper.net ([208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14246 for ; Wed, 22 Mar 2000 09:50:03 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id GAA66069; Wed, 22 Mar 2000 06:50:01 -0800 (PST) Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id GAA66038 for ; Wed, 22 Mar 2000 06:49:59 -0800 (PST) Received: from zsc4c002.corpwest.baynetworks.com (actually h0295.s86b1.BayNetworks.COM) by smtprch1.nortel.com; Wed, 22 Mar 2000 08:38:10 -0600 Received: from zbl6c002.corpeast.baynetworks.com ([132.245.205.52]) by zsc4c002.corpwest.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id HNYLR118; Wed, 22 Mar 2000 06:37:43 -0800 Received: from nortelnetworks.com (lead.engeast.baynetworks.com [192.32.148.52]) by zbl6c002.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id HNW5F2TT; Wed, 22 Mar 2000 09:37:42 -0500 Message-ID: <38D8DAB7.9480EE55@nortelnetworks.com> Date: Wed, 22 Mar 2000 09:37:43 -0500 From: "Rajesh Saluja" X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "vanik@future.futsoft.com" CC: "'isis-wg@external.juniper.net'" Subject: Re: [Isis-wg] Reg. multiple IP addr and Advt of L1 Addr in L2 Lsps References: <01BF93F4.D79A9A40.vanik@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 "vanisri .k" wrote: > Hi, > > I have doubts regarding the following. Please > clarify me. > > 1. > IS-IS allows multiple IP addresses assigned to > an physical interface. What is the significant of it > and where it is applied? You can support multinetting on one physical interface. > > > 2. > L2 Router advertises in its level 2 LSPs all the IP addresses > reachable in their area. Summary address can be configured, > otherwise all the level 1 Addresses obtained from the level 1 > LSPs has to be advertised. > My doubt is can we get the addresses from the "level 1 Forwarding Data base" > instead of "level1 LSPs". > RFC says (Sec 3.2 of 1195) these are determined from > level 1 LSPs. Should the l2 router collects all l1 reachable > addresses and the cost to reach them from level 1 LS data base, > if summary address is not configured. Spec says "address obtained from level1 LSP". It is an implementation choice whether you want to extract this information from L1 LSPs or forwarding database or some other data structure. Regards, Rajesh _______________________________________________ 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 Mar 23 01:15:11 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 BAA24369 for ; Thu, 23 Mar 2000 01:15:10 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id WAA66946; Wed, 22 Mar 2000 22:18:48 -0800 (PST) Received: from fsnt.future.futusoft.com ([203.197.140.35]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id WAA66918 for ; Wed, 22 Mar 2000 22:16:45 -0800 (PST) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futusoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Thu, 23 Mar 2000 11:47:36 +0530 Received: from cairo.future.futsoft.com ([172.16.1.37]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id LAA01815; Thu, 23 Mar 2000 11:28:41 +0530 Received: by localhost with Microsoft MAPI; Thu, 23 Mar 2000 11:42:46 +0530 Message-Id: <01BF94BC.E834CC40.vanik@future.futsoft.com> From: "vanisri .k" Reply-To: "vanik@future.futsoft.com" To: "'Jeff Parker'" Cc: "'isis-wg@external.juniper.net'" Subject: RE: [Isis-wg] Reg. multiple IP addr and Advt of L1 Addr in L2 Lsp s Date: Thu, 23 Mar 2000 11:42:44 +0530 Organization: Future Software X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 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 Jeff, My comments are inlined. > Hi, > > I have doubts regarding the following. Please > clarify me. > > 1. > IS-IS allows multiple IP addresses assigned to > an physical interface. What is the significant of it > and where it is applied? IP allows multiple IP addresses assigned the same interface. This can be used to allow a router to participate in multiple networks. ISIS just relays the information. [vanisri .k] Then how IS-IS should handle, when advertising reachable information about the nbr,having multiple IP addresses.? There will be multiple IP addresses (Reachable information) to that neighbor .? I am not much clear how IS-IS handles and relays the multiple IP addresses information. Could you please explain. > 2. > L2 Router advertises in its level 2 LSPs all the IP addresses > reachable in their area. Summary address can be configured, > otherwise all the level 1 Addresses obtained from the level 1 > LSPs has to be advertised. An optimization lets you reduce the network load by checking to see if the L1 route is comming from an L1/L2 router, which can be trusted to put it into L2 for you. > RFC says (Sec 3.2 of 1195) these are determined from > level 1 LSPs. Should the l2 router collects all l1 reachable > addresses and the cost to reach them from level 1 LS data base, > if summary address is not configured. > > Thanks > -vani There are a number of issues in your question: I'm not sure which you are asking about. [vanisri .k] My question was clarfied by Rajesh. My actual question was , How do the L1L2 Router collects the level 1 reachablity information, before it advertises in its level2 LSPs to other areas, from its level1 LSPs or Level 1 Forwarding Data base. ? Rajesh says, It is implementaion specific. - jeff parker - Lucent INS Thanks -vani _______________________________________________ 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 Mar 23 15:06:08 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 PAA28723 for ; Thu, 23 Mar 2000 15:06:07 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA67765; Thu, 23 Mar 2000 12:07:55 -0800 (PST) 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 MAA67740 for ; Thu, 23 Mar 2000 12:07:53 -0800 (PST) Received: from mshand-8kcdt (dhcp-171-69-71-168.cisco.com [171.69.71.168]) by jaws.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id UAA27338; Thu, 23 Mar 2000 20:00:11 GMT Message-Id: <4.2.2.20000323115830.00ac93a0@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 23 Mar 2000 12:00:29 +0000 To: "Rajesh Saluja" , "vanik@future.futsoft.com" From: Mike Shand Subject: Re: [Isis-wg] Reg. multiple IP addr and Advt of L1 Addr in L2 Lsps Cc: "'isis-wg@external.juniper.net'" In-Reply-To: <38D8DAB7.9480EE55@nortelnetworks.com> References: <01BF93F4.D79A9A40.vanik@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 09:37 22/03/2000 -0500, Rajesh Saluja wrote: >Spec says "address obtained from level1 LSP". It is an implementation choice >whether you want to extract this information from L1 LSPs or forwarding >database or some other data structure. But its important that what you extract is the REACHABLE addresses, not just any old addresses that happen to be skulking around in some unconnected L1 LSP. So in that sense you should get them from the RIB/FIB not from the raw LSP database. 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 Mar 23 15:19:56 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 PAA04141 for ; Thu, 23 Mar 2000 15:19:55 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA67834; Thu, 23 Mar 2000 12:22:48 -0800 (PST) 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 MAA67803 for ; Thu, 23 Mar 2000 12:22:46 -0800 (PST) Received: from bandito.nexabit.com (h135-17-240-4.outland.lucent.com [135.17.240.4]) by redbaron.nexabit.com (8.9.3/8.9.3) with ESMTP id PAA20908; Thu, 23 Mar 2000 15:14:14 -0500 Received: by bandito.nexabit.com with Internet Mail Service (5.5.2650.21) id ; Thu, 23 Mar 2000 15:14:09 -0500 Message-ID: From: Jeff Parker To: vanik@future.futsoft.com, "'Jeff Parker'" Cc: "'isis-wg@external.juniper.net'" Subject: RE: [Isis-wg] Reg. multiple IP addr and Advt of L1 Addr in L2 Lsp s Date: Thu, 23 Mar 2000 15:14:08 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" 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 > > 1. > > IS-IS allows multiple IP addresses assigned to > > an physical interface. What is the significant of it > > and where it is applied? > > IP allows multiple IP addresses assigned the same > interface. This can be used to allow a router to > participate in multiple networks. ISIS just relays > the information. > [vanisri .k] Then how IS-IS should handle, when advertising > reachable information about the nbr,having multiple IP addresses.? > There will be multiple IP addresses (Reachable information) > to that neighbor .? > I am not much clear how IS-IS handles and relays the multiple > IP addresses information. > Could you please explain. These IP Addresses could appear in two places: In the hello pkt sent out that port In the LSPs sent by that router If you have multiple IP addresses on a port, you could advertise one, both, or none in your L1 LSP and in your hellos. I think this is an implementation issue: but the principle of least surprise would probably suggest that you include both in Hellos and in LSPs. - jparker _______________________________________________ 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 Mar 23 15:36:00 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 PAA10603 for ; Thu, 23 Mar 2000 15:35:58 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA67895; Thu, 23 Mar 2000 12:38:11 -0800 (PST) Received: from yarilo.pluris.com (pluris.com [208.227.9.12]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA67867 for ; Thu, 23 Mar 2000 12:38:10 -0800 (PST) Received: from monterey.pluris.com (monterey.pluris.com [172.16.50.17]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id MAA02916; Thu, 23 Mar 2000 12:30:52 -0800 (PST) Received: by monterey-40.pluris.com with Internet Mail Service (5.5.2650.21) id ; Thu, 23 Mar 2000 12:30:52 -0800 Message-ID: From: Satish Dattatri To: "'Jeff Parker'" , vanik@future.futsoft.com Cc: "'isis-wg@external.juniper.net'" Subject: RE: [Isis-wg] Reg. multiple IP addr and Advt of L1 Addr in L2 Lsp s Date: Thu, 23 Mar 2000 12:30:43 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" 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 Jeff, Take a configuration of R1 and R2 in a area. Let R1 have 2 interfaces R1I1 and R1I2. R1 and R2 are connected via R1I2. Now, if R1I1 has multiple IP addresses, The only way R2 will know is by the LSP of R1 [ assume only isis is running;-) ] Then, where is the option of none of the IP reachability info in L1 LSP holds out? Well, there may be other cases where with a router sending none of the IP info still may have connectivity. But that does not mean protocol can have the option of not sending local reachability. Please let me know if I am missing something here. thanks, satish These IP Addresses could appear in two places: In the hello pkt sent out that port In the LSPs sent by that router If you have multiple IP addresses on a port, you could advertise one, both, or none in your L1 LSP and in your hellos. I think this is an implementation issue: but the principle of least surprise would probably suggest that you include both in Hellos and in LSPs. - jparker _______________________________________________ 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 Mar 23 15:55: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 PAA17595 for ; Thu, 23 Mar 2000 15:55:44 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA67963; Thu, 23 Mar 2000 13:00:00 -0800 (PST) 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 MAA67935 for ; Thu, 23 Mar 2000 12:59:57 -0800 (PST) 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 PAA21910; Thu, 23 Mar 2000 15:52:16 -0500 Received: by bandito.nexabit.com with Internet Mail Service (5.5.2650.21) id ; Thu, 23 Mar 2000 15:52:16 -0500 Message-ID: From: Jeff Parker To: Satish Dattatri Cc: "'isis-wg@external.juniper.net'" Subject: RE: [Isis-wg] Reg. multiple IP addr and Advt of L1 Addr in L2 Lsp s Date: Thu, 23 Mar 2000 15:52:14 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" 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 Satish - I will not try to defend the option "none", though I admit that I raised it earlier. There is a place for unnumbered interfaces, but that is another discussion. I am just trying to suggest that there is a great deal of leyway for implementations. There may be a reason to have a second IP address, and there may be a reason not to mention that address to the ISIS protocol. R2 will not know about it: that may be what the user wants. We do not want to be in the business of telling you how your users use the protocol. - jeff parker - I'm not sure if these opinions are mine, - much less those of Lucent Technologies. > Hi Jeff, > Take a configuration of R1 and R2 > in a area. Let R1 have 2 interfaces > R1I1 and R1I2. R1 and R2 are connected > via R1I2. > Now, if R1I1 has multiple IP addresses, > The only way R2 will know is by the LSP > of R1 [ assume only isis is running;-) ] > > Then, where is the option of none of the IP > reachability info in L1 LSP holds out? > > Well, there may be other cases where with a > router sending none of the IP info still may > have connectivity. But that does not mean > protocol can have the option of not sending > local reachability. > > Please let me know if I am missing something here. > thanks, > satish > > > These IP Addresses could appear in two places: > In the hello pkt sent out that port > In the LSPs sent by that router > > If you have multiple IP addresses on a port, you could > advertise one, both, or none in your L1 LSP and in your > hellos. I think this is an implementation issue: but > the principle of least surprise would probably suggest > that you include both in Hellos and in LSPs. > > - jparker > > _______________________________________________ > 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 Mar 23 16:12:04 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 QAA23728 for ; Thu, 23 Mar 2000 16:12:01 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA68025; Thu, 23 Mar 2000 13:13:23 -0800 (PST) Received: from siara.com (netscreen [209.10.58.71] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA68001 for ; Thu, 23 Mar 2000 13:13:21 -0800 (PST) Received: from siara.com (yoo-hoo.mtv.siara.com [192.168.40.63]) by siara.com (8.9.3-LCCHA/8.9.3/lccha Siara hub 1.4) with ESMTP id NAA23261; Thu, 23 Mar 2000 13:04:25 -0800 (PST) Message-Id: <200003232104.NAA23261@siara.com> To: Satish Dattatri cc: "'Jeff Parker'" , vanik@future.futsoft.com, "'isis-wg@external.juniper.net'" Subject: Re: [Isis-wg] Reg. multiple IP addr and Advt of L1 Addr in L2 Lsp s In-reply-to: Mail from Satish Dattatri dated Thu, 23 Mar 2000 12:30:43 PST Date: Thu, 23 Mar 2000 13:04:25 -0800 From: Naiming Shen 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 Jeff, ]Take a configuration of R1 and R2 ]in a area. Let R1 have 2 interfaces ]R1I1 and R1I2. R1 and R2 are connected ]via R1I2. ]Now, if R1I1 has multiple IP addresses, ]The only way R2 will know is by the LSP ]of R1 [ assume only isis is running;-) ] ] ]Then, where is the option of none of the IP ]reachability info in L1 LSP holds out? ] depends on if there is a need for R2 to know the IP address on R1I1. some IP addresses should be stay local only. so this is an implementation and configuration issue. even if R1I1 has isis configured on the interface, you don't have to stuff all the IP addresses on the LSPs, you have a choice say only put "primary" address there, or put all the addresses there, or even use some kind of filtering to selectively stuff part of the addresses there. An example is if you have a 10/x address on the interface as a secondary IP address, you may choose not to advertise it into your isis LSP. you can also use redistribution to selectively bring in your connected IP addresses using some kind of policy. ]Well, there may be other cases where with a ]router sending none of the IP info still may ]have connectivity. But that does not mean ]protocol can have the option of not sending ]local reachability. ] ]Please let me know if I am missing something here. ]thanks, ]satish ] ] ]These IP Addresses could appear in two places: ] In the hello pkt sent out that port ] In the LSPs sent by that router ] ]If you have multiple IP addresses on a port, you could ]advertise one, both, or none in your L1 LSP and in your ]hellos. I think this is an implementation issue: but ]the principle of least surprise would probably suggest ]that you include both in Hellos and in LSPs. ] ]- jparker ] ]_______________________________________________ ]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 - Naiming _______________________________________________ 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 Mar 24 01:56: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 BAA20069 for ; Fri, 24 Mar 2000 01:56:50 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id XAA68739; Thu, 23 Mar 2000 23:00:43 -0800 (PST) Received: from mailman.cisco.com (mailman.cisco.com [171.68.225.9]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id XAA68709 for ; Thu, 23 Mar 2000 23:00:41 -0800 (PST) Received: from emailid-pc.cisco.com (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id WAA25483 for ; Thu, 23 Mar 2000 22:53:27 -0800 (PST) Message-Id: <4.2.0.58.20000324005507.00d2bbb0@127.0.0.1> X-Sender: mbartell@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 24 Mar 2000 00:56:20 -0600 To: isis-wg@external.juniper.net From: Micah Bartell Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [Isis-wg] ISIS TE Draft 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 Do we have a new revision of the draft-ietf-isis-traffic? Revision 02 has expired. This Internet-Draft has expired and is no longer available. Unrevised documents placed in the Internet-Drafts directories have a maximum life of six months. After that time, they must be updated, or they will be deleted. This document was deleted on March 20, 2000. /mpb -- Micah Bartell, CCIE #5069 mbartell@cisco.com Network Consulting Engineer, NSA Phone: 972.364.8829 Cisco Systems, Inc Fax: 972.364.8829 -- The Network Works, No Excuses _______________________________________________ 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 Mar 24 11:36:41 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 LAA18864 for ; Fri, 24 Mar 2000 11:36:41 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA69483; Fri, 24 Mar 2000 08:39:43 -0800 (PST) Received: from smtprtp.ntcom.nortel.net (smtprtp.ntcom.nortel.net [137.118.22.15]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA69452 for ; Fri, 24 Mar 2000 08:39:40 -0800 (PST) Received: from zrtpd004.us.nortel.com (actually zrtpd004) by smtprtp.ntcom.nortel.net; Fri, 24 Mar 2000 11:31:56 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Fri, 24 Mar 2000 11:31:55 -0500 Message-ID: From: "Don Fedyk" To: Micah Bartell , isis-wg@external.juniper.net Subject: RE: [Isis-wg] ISIS TE Draft Date: Fri, 24 Mar 2000 11:31:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF95AE.76AE75BA" 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 message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF95AE.76AE75BA Content-Type: text/plain; charset="iso-8859-1" This is a good point. I will mention it at the Routing Area meeting. We are proposing extensions to this draft and OSPF. Neither WG is meeting at Adelaide though. Regards, Don > -----Original Message----- > From: Micah Bartell [mailto:mbartell@cisco.com] > Sent: Friday, March 24, 2000 1:56 AM > To: isis-wg@external.juniper.net > Subject: [Isis-wg] ISIS TE Draft > > > Do we have a new revision of the draft-ietf-isis-traffic? > > Revision 02 has expired. > > This Internet-Draft has expired and is no longer available. > Unrevised documents placed in the Internet-Drafts directories > have a maximum life of six months. After that time, they must > be updated, or they will be deleted. This document was > deleted on March 20, 2000. > > > /mpb > > > -- > Micah Bartell, CCIE #5069 mbartell@cisco.com > Network Consulting Engineer, NSA Phone: 972.364.8829 > Cisco Systems, Inc Fax: 972.364.8829 > -- > The Network Works, No Excuses > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > ------_=_NextPart_001_01BF95AE.76AE75BA Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Isis-wg] ISIS TE Draft

This is a good point. I will mention it at the = Routing
Area meeting. We are proposing extensions to this = draft and
OSPF. Neither WG is meeting at Adelaide = though.

Regards,
Don

> -----Original Message-----
> From: Micah Bartell [mailto:mbartell@cisco.com]=
> Sent: Friday, March 24, 2000 1:56 AM
> To: isis-wg@external.juniper.net
> Subject: [Isis-wg] ISIS TE Draft
>
>
> Do we have a new revision of the = draft-ietf-isis-traffic?
>
> Revision 02 has expired.
>
> This Internet-Draft has expired and is no = longer available.
> Unrevised documents placed in the = Internet-Drafts directories
> have a maximum life of six months. After that = time, they must
> be updated, or they will be deleted. This = document was
> deleted on March 20, 2000.
>
>
> /mpb
>
>
> --
> Micah Bartell, CCIE = #5069     =         =         mbartell@cisco.com
> Network Consulting Engineer, = NSA      =         Phone: 972.364.8829
> Cisco Systems, Inc    =         =         =         Fax: 972.364.8829
> --
> The Network Works, No Excuses
>
> = _______________________________________________
> Isis-wg mailing list  -  = Isis-wg@external.juniper.net
> http://external.juniper.net/mailman/listinfo/isis-wg
>

------_=_NextPart_001_01BF95AE.76AE75BA-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Sun Mar 26 12:57:03 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 MAA14572 for ; Sun, 26 Mar 2000 12:57:02 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA73898; Sun, 26 Mar 2000 10:01:48 -0800 (PST) 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 KAA73872 for ; Sun, 26 Mar 2000 10:01:46 -0800 (PST) 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 JAA03397; Sun, 26 Mar 2000 09:54:08 -0800 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 TAA00644; Sun, 26 Mar 2000 19:59:50 +0200 Message-Id: <200003261759.TAA00644@kraak.procket.com> Subject: Re: [Isis-wg] ISIS TE Draft To: mbartell@cisco.com (Micah Bartell) Date: Sun, 26 Mar 2000 19:59:50 +0200 (CEST) Cc: isis-wg@external.juniper.net In-Reply-To: <4.2.0.58.20000324005507.00d2bbb0@127.0.0.1> from "Micah Bartell" at Mar 24, 2000 12:56:20 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 > Do we have a new revision of the draft-ietf-isis-traffic? No. However, I will have a look at it in the near future, and get a new version out. Might take a few weeks, though. If anyone has any comments or remarks, please let me know. Henk. > Revision 02 has expired. > > This Internet-Draft has expired and is no longer available. Unrevised documents placed in the Internet-Drafts directories have a maximum life of six months. After that time, they must be updated, or they will be deleted. This document was deleted on March 20, 2000. > > > /mpb > > > -- > Micah Bartell, CCIE #5069 mbartell@cisco.com > Network Consulting Engineer, NSA Phone: 972.364.8829 > Cisco Systems, Inc Fax: 972.364.8829 > -- > The Network Works, No Excuses > > _______________________________________________ > 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