From owner-ospf@PEACH.EASE.LSOFT.COM Sun Jan 2 22:44:07 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02114 for ; Sun, 2 Jan 2005 22:44:06 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00F301FE@cherry.ease.lsoft.com>; 2 Jan 2005 22:44:04 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 51676854 for OSPF@PEACH.EASE.LSOFT.COM; Sun, 2 Jan 2005 22:43:58 -0500 Received: from 64.102.122.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sun, 2 Jan 2005 22:43:58 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 02 Jan 2005 22:43:58 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j033gLDX019086 for ; Sun, 2 Jan 2005 22:42:22 -0500 (EST) Received: from [10.82.225.222] (rtp-vpn1-478.cisco.com [10.82.225.222]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BEH95604; Sun, 2 Jan 2005 19:42:21 -0800 (PST) User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <200412292221.iBTMLv418987@windsor.research.att.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <41D8BF1D.1010400@cisco.com> Date: Sun, 2 Jan 2005 22:42:21 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: draft-ietf-ospf-ospfv3-auth-06.txt Ready for IESG review To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <200412292221.iBTMLv418987@windsor.research.att.com> Precedence: list Content-Transfer-Encoding: 7bit Bill Fenner wrote: >Thanks, Mukesh. I'll review it and put it on the IESG agenda for >January 6th. > > Hi Bill, Due to the volume of changes, we stated that we would do another WG last call. Thanks, Acee > Bill > > > From owner-ospf@PEACH.EASE.LSOFT.COM Sun Jan 2 22:57:04 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02680 for ; Sun, 2 Jan 2005 22:57:03 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00F30200@cherry.ease.lsoft.com>; 2 Jan 2005 22:57:01 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 51677447 for OSPF@PEACH.EASE.LSOFT.COM; Sun, 2 Jan 2005 22:56:56 -0500 Received: from 171.68.10.87 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sun, 2 Jan 2005 22:56:56 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by sj-iport-5.cisco.com with ESMTP; 02 Jan 2005 19:57:19 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j033uqW0015741 for ; Sun, 2 Jan 2005 22:56:52 -0500 (EST) Received: from [10.82.225.222] (rtp-vpn1-478.cisco.com [10.82.225.222]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BEH95762; Sun, 2 Jan 2005 19:56:51 -0800 (PST) User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <41D8C283.7060702@cisco.com> Date: Sun, 2 Jan 2005 22:56:51 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: WG Last Call on draft-ietf-ospf-ospfv3-auth-06.txt To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit This the start of the Working Group Last Call for draft-ietf-ospf-ospfv3-auth-06.txt - Authentication/Confidentiality for OSPFv3. All comments must be sent to the OSPF list by 12:00 AM EST on Wednesday, January 19th, 2005. A URL for this Internet-draft is provided below: http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-auth-06.txt Thanks, Acee & Rohit From owner-ospf@PEACH.EASE.LSOFT.COM Mon Jan 3 13:47:33 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25244 for ; Mon, 3 Jan 2005 13:47:33 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00F30DC1@cherry.ease.lsoft.com>; Mon, 3 Jan 2005 13:47:26 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 51765492 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 3 Jan 2005 13:47:25 -0500 Received: from 192.20.225.110 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 3 Jan 2005 13:47:25 -0500 Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by mail-blue.research.att.com (Postfix) with ESMTP id 0B3B819735F for ; Mon, 3 Jan 2005 13:33:45 -0500 (EST) Received: (from fenner@localhost) by windsor.research.att.com (8.11.6+Sun/8.8.5) id j03IlNW07575; Mon, 3 Jan 2005 10:47:23 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII References: <200412292221.iBTMLv418987@windsor.research.att.com> <41D8BF1D.1010400@cisco.com> Versions: dmail (solaris) 2.6d/makemail 2.10 Message-ID: <200501031847.j03IlNW07575@windsor.research.att.com> Date: Mon, 3 Jan 2005 10:47:21 -0800 Reply-To: Mailing List Sender: Mailing List From: Bill Fenner Subject: Re: draft-ietf-ospf-ospfv3-auth-06.txt Ready for IESG review To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list >Due to the volume of changes, we stated that we would do another WG last >call. Oops! Sorry for jumping the gun. I'll wait for your go-ahead. Bill From owner-ospf@PEACH.EASE.LSOFT.COM Mon Jan 3 15:51:48 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08770 for ; Mon, 3 Jan 2005 15:51:47 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.00F310CE@cherry.ease.lsoft.com>; Mon, 3 Jan 2005 15:51:42 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 51789197 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 3 Jan 2005 15:51:40 -0500 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 3 Jan 2005 15:41:40 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07962; Mon, 3 Jan 2005 15:41:37 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200501032041.PAA07962@ietf.org> Date: Mon, 3 Jan 2005 15:41:37 -0500 Reply-To: Mailing List Sender: Mailing List From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ospf-scalability-09.txt Comments: To: i-d-announce@ietf.org To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF. Title : Prioritized Treatment of Specific OSPF Packets and Congestion Avoidance Author(s) : G. Choudhury Filename : draft-ietf-ospf-scalability-09.txt Pages : 14 Date : 2005-1-3 This document recommends methods that are intended to improve the scalability and stability of large networks using OSPF (Open Shortest Path First) Version 2 protocol. The methods include processing OSPF Hellos and LSA (Link State Advertisement) Acknowledgments at a higher priority compared to other OSPF packets, and other congestion avoidance procedures. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-scalability-09.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ospf-scalability-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ospf-scalability-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-1-3151328.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ospf-scalability-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ospf-scalability-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-1-3151328.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jan 4 17:11:02 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27124 for ; Tue, 4 Jan 2005 17:11:01 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.00F33985@cherry.ease.lsoft.com>; Tue, 4 Jan 2005 17:10:58 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 51968443 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 4 Jan 2005 17:10:54 -0500 Received: from 64.102.122.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 4 Jan 2005 17:10:54 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 04 Jan 2005 17:22:26 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j04MArW0013858; Tue, 4 Jan 2005 17:10:53 -0500 (EST) Received: from [10.82.240.158] (rtp-vpn2-158.cisco.com [10.82.240.158]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BEI82215; Tue, 4 Jan 2005 14:10:51 -0800 (PST) User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <41DB146B.40907@cisco.com> Date: Tue, 4 Jan 2005 17:10:51 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Comments on draft-ietf-ospf-ospfv3-traffic-02.txt Comments: To: Kunihiro Ishiguro , Toshiaki Takada To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Kunihiro, Toshiaki, Here are my comments on this revision: 1. Section 1 - I still believe the statement that this draft is applicable to OSPFv2 should be removed. If it is applicable to OSPFv2, this has to be explicitly specified and I don't see a requirement to do this. 2. Based on our discussions, I believe section 2 is no longer a co-requisite draft since there is a separate router IPv6 address TLV. If this is indeed the case, section can be removed. 3. Section 7 - Add others who have commented on the draft (e.g., Nic Neate). 4. Section 8 - Split into normative and informative references. Remove reference [5] and make [3] and [4] informative. 5. Suggest using mnemonics for references: [1] -> [OSPFV3] [2] -> [OSPF-TE] [3] -> [O-GMPLS] [4] -> [TE-DIFF] 6. Add "IANA Considerations" section. Thanks, Acee From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jan 5 00:48:01 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28578 for ; Wed, 5 Jan 2005 00:48:00 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.00F34B04@cherry.ease.lsoft.com>; Wed, 5 Jan 2005 0:47:57 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 52014276 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 5 Jan 2005 00:47:54 -0500 Received: from 209.119.1.83 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 5 Jan 2005 00:47:54 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wnt.dc.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <7.FD807EE6@wnt.dc.lsoft.com>; Wed, 5 Jan 2005 0:47:54 -0500 Message-ID: Date: Wed, 5 Jan 2005 00:47:50 -0500 Reply-To: Mailing List Sender: Mailing List From: vishnuvardhan B Subject: Re: draft-ietf-ospf-multi-area-adj-03.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Hi, I am not able to find the interdependancy from the draft between primary adjacencies and the secondary adjacencies running on the same link . For example if the running ospf on the first adjacency is removed through external commands then what happens to the secondary adjacencies, should they continue to run as long as the physical link is up? Thanks&Regards, Vishnu From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jan 5 00:48:44 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28630 for ; Wed, 5 Jan 2005 00:48:43 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00F34A85@cherry.ease.lsoft.com>; Wed, 5 Jan 2005 0:48:43 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 52014358 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 5 Jan 2005 00:48:40 -0500 Received: from 209.119.1.83 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 5 Jan 2005 00:48:40 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wnt.dc.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <2.FEF0E5C5@wnt.dc.lsoft.com>; Wed, 5 Jan 2005 0:48:41 -0500 Message-ID: Date: Wed, 5 Jan 2005 00:48:27 -0500 Reply-To: Mailing List Sender: Mailing List From: vishnuvardhan B Subject: Re: draft-ietf-ospf-multi-area-adj-03.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Hi, I am not able to find the interdependancy from the draft between primary adjacencies and the secondary adjacencies running on the same link . For example if the running ospf on the first adjacency is removed through external commands then what happens to the secondary adjacencies, should they continue to run as long as the physical link is up? Thanks a lot for having a look at my query. Thanks&Regards, Vishnu From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jan 5 14:45:52 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04225 for ; Wed, 5 Jan 2005 14:45:52 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00F35F02@cherry.ease.lsoft.com>; Wed, 5 Jan 2005 14:45:51 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 52116914 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 5 Jan 2005 14:45:48 -0500 Received: from 171.68.227.75 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 5 Jan 2005 14:45:48 -0500 Received: from smirtoraw2k03 (sjc-vpn7-429.cisco.com [10.21.145.173]) by fire.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id j05Jjki03137 for ; Wed, 5 Jan 2005 11:45:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 Importance: Normal Message-ID: <02db01c4f35f$26b9f3e0$6001a8c0@amer.cisco.com> Date: Wed, 5 Jan 2005 14:45:41 -0500 Reply-To: Mailing List Sender: Mailing List From: Sina Mirtorabi Subject: Re: draft-ietf-ospf-multi-area-adj-03.txt To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit Vishnu, ->-----Original Message----- ->From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On ->Behalf Of vishnuvardhan B ->Sent: Wednesday, January 05, 2005 12:48 AM ->To: OSPF@PEACH.EASE.LSOFT.COM ->Subject: Re: draft-ietf-ospf-multi-area-adj-03.txt -> -> ->Hi, ->I am not able to find the interdependancy from the draft ->between primary adjacencies and the secondary adjacencies ->running on the same link . For example if the running ospf on ->the first adjacency is removed through external commands then ->what happens to the secondary adjacencies, should they ->continue to run as long as the physical link is up? ->Thanks&Regards, Vishnu There is no interdependency between the adjacencies, the removal of one adjacency does not affect others.. Sina From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jan 5 14:59:22 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05717 for ; Wed, 5 Jan 2005 14:59:22 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00F36048@cherry.ease.lsoft.com>; Wed, 5 Jan 2005 14:59:22 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 52118807 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 5 Jan 2005 14:59:21 -0500 Received: from 64.102.122.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 5 Jan 2005 14:59:21 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 05 Jan 2005 14:59:21 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j05JxJW0014351 for ; Wed, 5 Jan 2005 14:59:19 -0500 (EST) Received: from [64.102.48.112] (dhcp-64-102-48-112.cisco.com [64.102.48.112]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BEJ47584; Wed, 5 Jan 2005 11:59:18 -0800 (PST) User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <41DC4716.9000309@cisco.com> Date: Wed, 5 Jan 2005 14:59:18 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: OSPF List Posting Problems To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Those of you who have posted to the OSPF list within the last month may have noticed a mail server reflection problem manifesting itself in a list rejection message from the OSPF list server. We believe we have unsubscribed the stale email address causing the problem (though, IMHO the mail server should not simply reflect the message). This message will serve as a test. Thanks, Acee & Rohit From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jan 5 19:11:46 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06785 for ; Wed, 5 Jan 2005 19:11:44 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00F3715D@cherry.ease.lsoft.com>; Wed, 5 Jan 2005 19:11:40 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 52147431 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 5 Jan 2005 19:11:35 -0500 Received: from 171.68.227.75 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 5 Jan 2005 19:11:35 -0500 Received: from smirtoraw2k03 (rtp-vpn2-510.cisco.com [10.82.241.254]) by fire.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id j060BXi17950 for ; Wed, 5 Jan 2005 16:11:33 -0800 (PST) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_07FD_01C4F35A.5F3FA7F0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 Importance: Normal Message-ID: <07fc01c4f384$4815aff0$6001a8c0@amer.cisco.com> Date: Wed, 5 Jan 2005 19:11:33 -0500 Reply-To: Mailing List Sender: Mailing List From: Sina Mirtorabi Subject: I-D ACTION:draft-mirtorabi-ospf-ud-link-00.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_07FD_01C4F35A.5F3FA7F0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Folks, This is a proposal to run OSPF over unidirectional links, comments are welcome Thanks Sina ------ A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Support of unidirectional links in OSPFv2 Author(s) : S. Mirtorabi, et al. Filename : draft-mirtorabi-ospf-ud-link-00.txt Pages : 10 Date : 2005-1-5 =09 This document describes how to support unidirectional links in OSPF=20 and addresses its challenges. Unidirectional link routing (UDLR)=20 describes a link-layer tunneling mechanism in order to abstract the network layer from unidirectional links and makes it transparent to routing protocols. Although this solution can be used, it can be=20 cumbersome for user due to configured tunnels and generates extra overhead for control packets and encapsulation of tunnels. This document proposes the necessary extensions to OSPF in order to support unidirectional links. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mirtorabi-ospf-ud-link-00.txt To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of = the message. =20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the = username "anonymous" and a password of your e-mail address. After logging in, = type "cd internet-drafts" and then "get draft-mirtorabi-ospf-ud-link-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-mirtorabi-ospf-ud-link-00.txt". =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -------------------------------------------------------------------------= CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY -------------------------------------------------------------------------= In order to maintain computing infrastructure integrity, Cisco Systems Enterprise Messaging Services and InfoSec teams have set a mail policy disallowing executable attachments in email. This message contained an executable attachment type that is prohibited=20 by this policy. The attachment has been removed from this message and=20 copied to quarantine by our systems. It will be held in quarantine for = seven days in the event that the content needs to be retrieved. Please be aware many viruses attempt to look like legitimate email or=20 notifications from anti-virus systems. We will clearly mark a seperation between our notifications and the original email as follows: "CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY" For further reference information about viruses and email antivirus=20 efforts within Cisco, please visit: http://wwwin.cisco.com/it/ems/services/antiviral If your concern isn't addressed by the information in this notification=20 or the above web page, you may open a support request: http://wwwin.cisco.com/support/ Select "Messaging", "Email-Related", "Mail Routing" Please include in the text of your case the following information: * Full headers of the message. Documentation on displaying the full=20 headers is available at this URL: http://wwwin.cisco.com/support/library/faqs/solution002471.html=20 * This unique quarantine identifier: j05LCrWL006241 If the matter is urgent, you may follow up by calling one of the below=20 referenced numbers. Please make every effort to provide the above=20 requested information via the support web tool prior to calling as it=20 will greatly aid the resolution of your issue. Americas: 1 408 526 8888 Asiapac +61 2 8446 8888 EMEA +31 20 485 4888 Japan +81 3 5549 6888 US (Toll Free) 1| 800| 888| 8187| (ext.68888) Thank you for your cooperation, Enterprise Messaging Services Cisco Systems, Inc ------=_NextPart_000_07FD_01C4F35A.5F3FA7F0 Content-Type: text/plain; name="ATT01960.txt" Content-Disposition: attachment; filename="ATT01960.txt" Content-Transfer-Encoding: 7bit _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce ------=_NextPart_000_07FD_01C4F35A.5F3FA7F0-- From owner-ospf@PEACH.EASE.LSOFT.COM Thu Jan 6 03:36:22 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21065 for ; Thu, 6 Jan 2005 03:36:22 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00F38283@cherry.ease.lsoft.com>; Thu, 6 Jan 2005 3:36:20 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 52187477 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 6 Jan 2005 03:36:19 -0500 Received: from 203.199.83.247 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 6 Jan 2005 03:36:17 -0500 Received: (qmail 31057 invoked by uid 510); 6 Jan 2005 08:37:42 -0000 Received: from unknown (203.126.136.220) by rediffmail.com via HTTP; 06 jan 2005 08:37:42 -0000 MIME-Version: 1.0 Content-type: multipart/alternative; boundary="Next_1105000662---0-203.199.83.247-31016" Message-ID: <20050106083742.31056.qmail@mailweb34.rediffmail.com> Date: Thu, 6 Jan 2005 08:37:42 -0000 Reply-To: Mailing List Sender: Mailing List From: Vivek Dubey Subject: Re: draft-ietf-ospf-cap-04.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This is a multipart mime message --Next_1105000662---0-203.199.83.247-31016 Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Acee,=0ASorry for delayed response.=0A=0AMy thoughts:=0A- Save OSPF capa= bilities (TLV 1), other capabilities/TLV (like TLV 2 =0A etc), mostly woul= d be opaque to OSPF, i.e depending on required =0A distribution in routing= domain, how they are distributed (OSPF =0A flooding scopes)is decided. Do= nt see why for such TLVs content be =0A affected by flooding scope.=0A = =0A That is, taking TLV or sub-tlv, for a particular router,=0A it should= represent consistent view across different flooding =0A scopes. =0A=0A1)R= outer X is connected to Router A(through normal Areas - A1 and A2)=0A=0A A= ssume there is TLV TV1 (opaque to OSPF), having bits (B1, B2)=0A represent= ing different capabilities.=0A=0A Router A capabilities flooded (based on = policy/configuration):=0A Area A1 (Type 10): TV1 - Bits(1,0)=0A Area A2 (= Type 10): TV1 - Bits(0,1)=0A=0A Now at Router X, one will maintain some ki= nd of centalized database =0A for advertised opaque capabilities of Router= A (these should not be =0A associated with OSPF AREA as TLV itself is opa= que to OSPF).=0A=0A Router X database: Router A Capability: TV1 (1,1)=0A= =0A Dont see any benefit of having different TLV contents in different=0A = areas in such cases.=0A=0A2)Router A capabilities flooded (based on policy= /configuration):=0A Area A1 (Type 10): TV1 - Bits(1,0)=0A Area A2 (Type 1= 0): TV1 - Bits(0,1)=0A=0A Router X database: Router A Capability: TV1 (1,1= )=0A=0A Next Area A1 adjacency is lost between Router A and Router X.=0A = Resulting in flushing of RI OPQ LSA in that area.=0A=0A What should than R= outer X database contain ???=0A=0A Router X database: Router A Capability:= TV1 (1,1)=0A OR=0A Router X database: Router A Capability: TV1 (0,1)= =0A=0A-Vivek =A0=0A=0A=0AOn Sun, 19 Dec 2004 Acee Lindem wrote :=0A>Hi Vi= vek,=0A>Independent of the capabilities LSA application, I don't see why a= =0A>router couldn't have different capabilities in different areas dependen= t=0A>on configuration or policy. What do you see wrong with this?=0A>=0A>Sp= eaking as work group member,=0A>Acee=0A>=0A>Vivek Dubey wrote:=0A>=0A>>JP,= =0A>>Comments inlined:=0A>>=0A>>Indeed. In the case of TE, there are variou= s cases where a router may=0A>>want to advertise a capability with differen= t flooding scopes thus two=0A>>different opaque LSAs. For instance, a route= r may belong to two=0A>>different meshes of TE LSPs, one local to its area = (RI LSA of Type 10)=0A>>one across the routing domain (RI LSA of Type 11).= =0A>>=0A>>vivek> If i understand correctly you are referring to the case wh= en router has attached NSSA/STUB area's, otherwise RI LSA of Type 11, would= suffice.=0A>>=0A>>The same TLV (automesh) is used, with different contents= , carried in different LSA (type 10 and 11).=0A>>=0A>>vivek> Why same TLV i= s required to carry different contents in different scoped LSAs. What if sa= me contents are carried in both Type 10 and Type 11 RI opaque LSAs. Are we = intending to hide some information across different OSPF flooding scopes ? = Since router's capability is independent of "Flooding Scopes", that should = not be the case.=0A>>=0A>>Thanks=0A>>Vivek=0A>>=0A>>=0A>>=0A>>=0A>>On Wed, = 08 Dec 2004 JP Vasseur wrote :=0A>> >Hi Vivek,=0A>> >=0A>> >On Dec 7, 2004,= at 5:16 PM, Acee Lindem wrote:=0A>> >=0A>> >>Hi Vivek,=0A>> >>=0A>> >>=0A>= > >>Vivek Dubey wrote:=0A>> >>=0A>> >>>Peter,=0A>> >>>=0A>> >>>1) In case o= f ABR analogy, the information was directly relevant to=0A>> >>> OSPF rout= ing and even than it was provided as configuration option,=0A>> >>> not a = "should" condition.=0A>> >>>=0A>> >>I think the configuration option is imp= lementation specific. Although=0A>> >>it is=0A>> >>not covered explicitly I= think RFC 3103 implies an ABR will=0A>> >>redistribute=0A>> >>into both at= tached NSSAs and regular areas.=0A>> >>=0A>> >>=0A>> >>>=0A>> >>> Here, OS= PF RI Opaque LSA is used for both:=0A>> >>> a) Advertising router's OSPF c= apabilities (TLV 1)=0A>> >>> b) Capablities Opaque to OSPF (Any future TLV= s defined)=0A>> >>>=0A>> >>> And since flooding scope is per TLV and depen= ds on local policy,=0A>> >>> there should be no dependency on Type's of ar= ea configured at OSPF=0A>> >>> level.=0A>> >>>=0A>> >>>2)=0A>> >>>draft>An= OSPF router MAY advertise different capabilities when both=0A>> >>> N= SSA/stub area type 10 LSA(s) and an AS scoped type 11 opaque=0A>> >>> = LSA is advertised.=0A>> >>>vivek> Capabilities here should map to different= TLV's ??=0A>> >>>=0A>> >>>Peter>I guess it can be different TLVs or differ= ent content in the=0A>> >>>same TLV.=0A>> >>>=0A>> >>>vivek> Different cont= ent in same TLV, advertised in different scoped=0A>> >>> LSAs (Type 10= and Type 11). Doesnt seems a good idea to me.=0A>> >>> Any possible s= cenarios?=0A>> >>>=0A>> >>JP - can you take a shot at this? I seem to remem= ber that you had a=0A>> >>scenario in minde.=0A>> >>=0A>> >=0A>> >Indeed. I= n the case of TE, there are various cases where a router may=0A>> >want to = advertise a capability with different flooding scopes thus two=0A>> >differ= ent opaque LSAs. For instance, a router may belong to two=0A>> >different m= eshes of TE LSPs, one local to its area (RI LSA of Type 10)=0A>> >one acros= s the routing domain (RI LSA of Type 11). The same TLV=0A>> >(automesh) is = used, with different contents, carried in different LSA=0A>> >(type 10 and = 11).=0A>> >=0A>> >Thanks.=0A>> >=0A>> >JP.=0A>> >=0A>> >>Thanks,=0A>> >>Ace= e=0A>> >>=0A>> >>>=0A>> >>>Thanks=0A>> >>>Vivek=0A>> >>>=0A>> >>>=0A>> >>>= =0A>> >>>=0A>> >>>=0A>> >>>On Tue, 07 Dec 2004 Peter Psenak wrote :=0A>> >>= > >Vivek,=0A>> >>> >=0A>> >>> >Vivek Dubey wrote:=0A>> >>> >>Hi,=0A>> >>> >= >Section 2.3:=0A>> >>> >>draft>TLV flooding scope rules will be specified o= n a per-TLV basis=0A>> >>> >>draft>If a type 11 opaque LSA is chosen, the o= riginating router=0A>> >>>should=0A>> >>> >> also advertise type 10 LS= A(s) into any attached NSSA/stub area=0A>> >>> >>=0A>> >>> >>vivek) If scop= e of TLV is defined to be AS (Type 11), why should,=0A>> >>>the=0A>> >>> >>= originating router advertise type 10 LSA(s) into any=0A>> >>> >> = attached NSSA/stub area ? Idea seems to get the capabilities=0A>> >>> >> = advertised to NSSA/STUB neighbors of originating router. But=0A>> >>> >= > what about NSSA/STUB areas attached not to "originating"=0A>> >>> >>= routers??=0A>> >>> >=0A>> >>> >an analogy is when you have an ABR con= nected to backbone area and=0A>> >>>NSSA=0A>> >>> >area and you redistribut= e routes from some external source. ABR will=0A>> >>> >generate Type-5 exte= rnal LSA, plus it can be configured to advertise=0A>> >>> >Type-7 LSA to th= e NSSA area for the same prefix.=0A>> >>> >If you have another ASBR somewhe= re in backbone area, Type-5 LSAs it=0A>> >>> >generates will not get propag= ated to NSSA area.=0A>> >>> >=0A>> >>> >>=0A>> >>> >>draft>An OSPF router M= AY advertise different capabilities when both=0A>> >>> >> NSSA/stub ar= ea type 10 LSA(s) and an AS scoped type 11 opaque=0A>> >>> >> LSA is a= dvertised.=0A>> >>> >>vivek> Capabilities here should map to different TLV'= s ??=0A>> >>> >=0A>> >>> >I guess it can be different TLVs or different con= tent in the same=0A>> >>>TLV.=0A>> >>> >=0A>> >>> >Peter=0A>> >>> >=0A>> >>= > >>=0A>> >>> >>Thanks=0A>> >>> >>Vivek=0A>> >>> >>=0A>> >>> >>=0A>> >>> >>= =0A>> >>> >>=0A>> >>>=0A= >> >>>=0A>> >>>=0A>> >>>= =0A>> >>=0A>>=0A>>=0A>>= =0A --Next_1105000662---0-203.199.83.247-31016 Content-type: text/html; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

=0AHi Acee,
=0ASorry for delayed response.
=0A
=0AMy thoughts:<= BR>=0A- Save OSPF capabilities (TLV 1), other capabilities/TLV (like TLV 2 =
=0A  etc), mostly would be opaque to OSPF, i.e depending on requir= ed
=0A  distribution in routing domain, how they are distributed (= OSPF
=0A  flooding scopes)is decided. Dont see why for such TLVs c= ontent be
=0A  affected by flooding scope.
=0A 
=0A&nb= sp; That is, taking TLV or sub-tlv, for a particular router,
=0A  i= t should represent consistent view across different flooding
=0A  = scopes.
=0A
=0A1)Router X is connected to Router A(through normal Ar= eas - A1 and A2)
=0A
=0A  Assume there is TLV TV1 (opaque to OSP= F), having bits (B1, B2)
=0A  representing different capabilities.<= BR>=0A
=0A  Router A capabilities flooded (based on policy/configur= ation):
=0A  Area A1 (Type 10): TV1 - Bits(1,0)
=0A  Area A= 2 (Type 10): TV1 - Bits(0,1)
=0A
=0A  Now at Router X, one will = maintain some kind of centalized database
=0A  for advertised opaq= ue capabilities of Router A (these should not be
=0A  associated w= ith OSPF AREA as TLV itself is opaque to OSPF).
=0A
=0A  Router = X database: Router A Capability: TV1 (1,1)
=0A
=0A  Dont see any= benefit of having different TLV contents in different
=0A  areas i= n such cases.
=0A
=0A2)Router A capabilities flooded (based on policy= /configuration):
=0A  Area A1 (Type 10): TV1 - Bits(1,0)
=0A&nbs= p; Area A2 (Type 10): TV1 - Bits(0,1)
=0A
=0A  Router X database= : Router A Capability: TV1 (1,1)
=0A
=0A  Next Area A1 adjacency= is lost between Router A and Router X.
=0A  Resulting in flushing = of RI OPQ LSA in that area.
=0A
=0A  What should than Router X d= atabase contain ???
=0A
=0A  Router X database: Router A Capabil= ity: TV1 (1,1)
=0A    OR
=0A  Router X database: Rout= er A Capability: TV1 (0,1)
=0A
=0A-Vivek   
=0A
=0A<= BR>=0AOn Sun, 19 Dec 2004 Acee Lindem wrote :
=0A>Hi Vivek,
=0A>= ;Independent of the capabilities LSA application, I don't see why a
=0A&= gt;router couldn't have different capabilities in different areas dependent=
=0A>on configuration or policy. What do you see wrong with this?
= =0A>
=0A>Speaking as work group member,
=0A>Acee
=0A><= BR>=0A>Vivek Dubey wrote:
=0A>
=0A>>JP,
=0A>>Com= ments inlined:
=0A>>
=0A>>Indeed. In the case of TE, ther= e are various cases where a router may
=0A>>want to advertise a ca= pability with different flooding scopes thus two
=0A>>different op= aque LSAs. For instance, a router may belong to two
=0A>>different= meshes of TE LSPs, one local to its area (RI LSA of Type 10)
=0A>>= ;one across the routing domain (RI LSA of Type 11).
=0A>>
=0A&g= t;>vivek> If i understand correctly you are referring to the case whe= n router has attached NSSA/STUB area's, otherwise RI LSA of Type 11, would = suffice.
=0A>>
=0A>>The same TLV (automesh) is used, with= different contents, carried in different LSA (type 10 and 11).
=0A>&= gt;
=0A>>vivek> Why same TLV is required to carry different con= tents in different scoped LSAs. What if same contents are carried in both T= ype 10 and Type 11 RI opaque LSAs. Are we intending to hide some informatio= n across different OSPF flooding scopes ? Since router's capability is inde= pendent of "Flooding Scopes", that should not be the case.
=0A= >>
=0A>>Thanks
=0A>>Vivek
=0A>>
=0A>= >
=0A>>
=0A>>
=0A>>On Wed, 08 Dec 2004 JP Vas= seur wrote :
=0A>> >Hi Vivek,
=0A>> >
=0A>>= ; >On Dec 7, 2004, at 5:16 PM, Acee Lindem wrote:
=0A>> >=0A>> >>Hi Vivek,
=0A>> >>
=0A>> >&= gt;
=0A>> >>Vivek Dubey wrote:
=0A>> >>
= =0A>> >>>Peter,
=0A>> >>>
=0A>> &= gt;>>1) In case of ABR analogy, the information was directly relevant= to
=0A>> >>>  OSPF routing and even than it was pro= vided as configuration option,
=0A>> >>>  not a &quo= t;should" condition.
=0A>> >>>
=0A>> >&g= t;I think the configuration option is implementation specific. Although
= =0A>> >>it is
=0A>> >>not covered explicitly I t= hink RFC 3103 implies an ABR will
=0A>> >>redistribute
= =0A>> >>into both attached NSSAs and regular areas.
=0A>&= gt; >>
=0A>> >>
=0A>> >>>
=0A>= > >>>  Here, OSPF RI Opaque LSA is used for both:
=0A&g= t;> >>>  a) Advertising router's OSPF capabilities (TLV 1)=
=0A>> >>>  b) Capablities Opaque to OSPF (Any futur= e TLVs defined)
=0A>> >>>
=0A>> >>>&nbs= p; And since flooding scope is per TLV and depends on local policy,
=0A&= gt;> >>>  there should be no dependency on Type's of area = configured at OSPF
=0A>> >>>  level.
=0A>> = >>>
=0A>> >>>2)
=0A>> >>>draft= >An OSPF router MAY advertise different capabilities when both
=0A>= ;> >>>      NSSA/stub area type 10 LSA(s) and an= AS scoped type 11 opaque
=0A>> >>>      L= SA is advertised.
=0A>> >>>vivek> Capabilities here sh= ould map to different TLV's ??
=0A>> >>>
=0A>> &= gt;>>Peter>I guess it can be different TLVs or different content i= n the
=0A>> >>>same TLV.
=0A>> >>>
= =0A>> >>>vivek> Different content in same TLV, advertised= in different scoped
=0A>> >>>      LSAs (= Type 10 and Type 11). Doesnt seems a good idea to me.
=0A>> >&g= t;>      Any possible scenarios?
=0A>> >>&= gt;
=0A>> >>JP - can you take a shot at this? I seem to reme= mber that you had a
=0A>> >>scenario in minde.
=0A>>= ; >>
=0A>> >
=0A>> >Indeed. In the case of TE= , there are various cases where a router may
=0A>> >want to adv= ertise a capability with different flooding scopes thus two
=0A>> = >different opaque LSAs. For instance, a router may belong to two
=0A&= gt;> >different meshes of TE LSPs, one local to its area (RI LSA of T= ype 10)
=0A>> >one across the routing domain (RI LSA of Type 11= ). The same TLV
=0A>> >(automesh) is used, with different conte= nts, carried in different LSA
=0A>> >(type 10 and 11).
=0A&g= t;> >
=0A>> >Thanks.
=0A>> >
=0A>> &= gt;JP.
=0A>> >
=0A>> >>Thanks,
=0A>> &g= t;>Acee
=0A>> >>
=0A>> >>>
=0A>&g= t; >>>Thanks
=0A>> >>>Vivek
=0A>> >&= gt;>
=0A>> >>>
=0A>> >>>
=0A>&= gt; >>>
=0A>> >>>
=0A>> >>>On = Tue, 07 Dec 2004 Peter Psenak wrote :
=0A>> >>> >Vivek= ,
=0A>> >>> >
=0A>> >>> >Vivek Du= bey wrote:
=0A>> >>> >>Hi,
=0A>> >>&= gt; >>Section 2.3:
=0A>> >>> >>draft>TLV f= looding scope rules will be specified on a per-TLV basis
=0A>> >= ;>> >>draft>If a type 11 opaque LSA is chosen, the originati= ng router
=0A>> >>>should
=0A>> >>> >= ;>      also advertise type 10 LSA(s) into any attached N= SSA/stub area
=0A>> >>> >>
=0A>> >>&= gt; >>vivek) If scope of TLV is defined to be AS (Type 11), why shoul= d,
=0A>> >>>the
=0A>> >>> >> = ;     originating router advertise type 10 LSA(s) into any
=0A= >> >>> >>      attached NSSA/stub area = ? Idea seems to get the capabilities
=0A>> >>> >>&n= bsp;     advertised to NSSA/STUB neighbors of originating router.= But
=0A>> >>> >>      what about NS= SA/STUB areas attached not to "originating"
=0A>> >&g= t;> >>      routers??
=0A>> >>> &= gt;
=0A>> >>> >an analogy is when you have an ABR conn= ected to backbone area and
=0A>> >>>NSSA
=0A>> &= gt;>> >area and you redistribute routes from some external source.= ABR will
=0A>> >>> >generate Type-5 external LSA, plu= s it can be configured to advertise
=0A>> >>> >Type-7 = LSA to the NSSA area for the same prefix.
=0A>> >>> >I= f you have another ASBR somewhere in backbone area, Type-5 LSAs it
=0A&g= t;> >>> >generates will not get propagated to NSSA area.
= =0A>> >>> >
=0A>> >>> >>
=0A&g= t;> >>> >>draft>An OSPF router MAY advertise different= capabilities when both
=0A>> >>> >>    &= nbsp; NSSA/stub area type 10 LSA(s) and an AS scoped type 11 opaque
=0A&= gt;> >>> >>      LSA is advertised.
=0A= >> >>> >>vivek> Capabilities here should map to dif= ferent TLV's ??
=0A>> >>> >
=0A>> >>>= ; >I guess it can be different TLVs or different content in the same
= =0A>> >>>TLV.
=0A>> >>> >
=0A>>= ; >>> >Peter
=0A>> >>> >
=0A>> &g= t;>> >>
=0A>> >>> >>Thanks
=0A>&g= t; >>> >>Vivek
=0A>> >>> >>
=0A&g= t;> >>> >>
=0A>> >>> >>
=0A>= ;> >>> >><http://clients.rediff.com/signature/track_si= g.asp>
=0A>> >>>
=0A>> >>>
=0A>= ;> >>>
=0A>> >>><http://clients.rediff.com= /signature/track_sig.asp>
=0A>> >>
=0A>>
=0A&= gt;>
=0A>><http://clients.rediff.com/signature/track_sig.asp= >
=0A=0A

=0A

=0A=0A --Next_1105000662---0-203.199.83.247-31016-- From owner-ospf@PEACH.EASE.LSOFT.COM Thu Jan 6 07:24:44 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02792 for ; Thu, 6 Jan 2005 07:24:44 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00F385C5@cherry.ease.lsoft.com>; Thu, 6 Jan 2005 7:24:43 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 52229051 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 6 Jan 2005 07:24:42 -0500 Received: from 64.102.122.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 6 Jan 2005 07:24:42 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 06 Jan 2005 07:36:29 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j06COdW0025876 for ; Thu, 6 Jan 2005 07:24:40 -0500 (EST) Received: from [10.82.240.191] (rtp-vpn2-191.cisco.com [10.82.240.191]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BEJ88663; Thu, 6 Jan 2005 04:24:38 -0800 (PST) User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <20050106083742.31056.qmail@mailweb34.rediffmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <41DD2E05.1030808@cisco.com> Date: Thu, 6 Jan 2005 07:24:37 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: draft-ietf-ospf-cap-04.txt To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <20050106083742.31056.qmail@mailweb34.rediffmail.com> Precedence: list Content-Transfer-Encoding: 7bit Hi Vivek, See inline. Vivek Dubey wrote: > Hi Acee, > Sorry for delayed response. > > My thoughts: > - Save OSPF capabilities (TLV 1), other capabilities/TLV (like TLV 2 > etc), mostly would be opaque to OSPF, i.e depending on required > distribution in routing domain, how they are distributed (OSPF > flooding scopes)is decided. Dont see why for such TLVs content be > affected by flooding scope. > In most cases they will. However, we want to allow for situations where a capability is enabled in one area but not another. > > That is, taking TLV or sub-tlv, for a particular router, > it should represent consistent view across different flooding > scopes. > > 1)Router X is connected to Router A(through normal Areas - A1 and A2) > > Assume there is TLV TV1 (opaque to OSPF), having bits (B1, B2) > representing different capabilities. > > Router A capabilities flooded (based on policy/configuration): > Area A1 (Type 10): TV1 - Bits(1,0) > Area A2 (Type 10): TV1 - Bits(0,1) > > Now at Router X, one will maintain some kind of centalized database > for advertised opaque capabilities of Router A (these should not be > associated with OSPF AREA as TLV itself is opaque to OSPF). > > Router X database: Router A Capability: TV1 (1,1) > > Dont see any benefit of having different TLV contents in different > areas in such cases. > If the function corresponding to the capability is also scoped at the area level, then it makes sense to only advertise it at that level. I could add a sentence to that effect. > > 2)Router A capabilities flooded (based on policy/configuration): > Area A1 (Type 10): TV1 - Bits(1,0) > Area A2 (Type 10): TV1 - Bits(0,1) > > Router X database: Router A Capability: TV1 (1,1) > > Next Area A1 adjacency is lost between Router A and Router X. > Resulting in flushing of RI OPQ LSA in that area. > LSAs aren't flushed when an adjacency goes down but it shouldn't be used if the corresponding router is unreachable. Eventually, it will age out. > > What should than Router X database contain ??? > > Router X database: Router A Capability: TV1 (1,1) > OR > Router X database: Router A Capability: TV1 (0,1) > Router X's area A2 database will contain the latter. The capability LSA for Router A in area A1 database is no longer applicable since Router A is unreachable. > > -Vivek > > > On Sun, 19 Dec 2004 Acee Lindem wrote : > >Hi Vivek, > >Independent of the capabilities LSA application, I don't see why a > >router couldn't have different capabilities in different areas dependent > >on configuration or policy. What do you see wrong with this? > > > >Speaking as work group member, > >Acee > > > >Vivek Dubey wrote: > > > >>JP, > >>Comments inlined: > >> > >>Indeed. In the case of TE, there are various cases where a router may > >>want to advertise a capability with different flooding scopes thus two > >>different opaque LSAs. For instance, a router may belong to two > >>different meshes of TE LSPs, one local to its area (RI LSA of Type 10) > >>one across the routing domain (RI LSA of Type 11). > >> > >>vivek> If i understand correctly you are referring to the case when > router has attached NSSA/STUB area's, otherwise RI LSA of Type 11, > would suffice. > >> > >>The same TLV (automesh) is used, with different contents, carried in > different LSA (type 10 and 11). > >> > >>vivek> Why same TLV is required to carry different contents in > different scoped LSAs. What if same contents are carried in both Type > 10 and Type 11 RI opaque LSAs. Are we intending to hide some > information across different OSPF flooding scopes ? Since router's > capability is independent of "Flooding Scopes", that should not be the > case. > >> > >>Thanks > >>Vivek > >> > >> > >> > >> > >>On Wed, 08 Dec 2004 JP Vasseur wrote : > >> >Hi Vivek, > >> > > >> >On Dec 7, 2004, at 5:16 PM, Acee Lindem wrote: > >> > > >> >>Hi Vivek, > >> >> > >> >> > >> >>Vivek Dubey wrote: > >> >> > >> >>>Peter, > >> >>> > >> >>>1) In case of ABR analogy, the information was directly relevant to > >> >>> OSPF routing and even than it was provided as configuration > option, > >> >>> not a "should" condition. > >> >>> > >> >>I think the configuration option is implementation specific. Although > >> >>it is > >> >>not covered explicitly I think RFC 3103 implies an ABR will > >> >>redistribute > >> >>into both attached NSSAs and regular areas. > >> >> > >> >> > >> >>> > >> >>> Here, OSPF RI Opaque LSA is used for both: > >> >>> a) Advertising router's OSPF capabilities (TLV 1) > >> >>> b) Capablities Opaque to OSPF (Any future TLVs defined) > >> >>> > >> >>> And since flooding scope is per TLV and depends on local policy, > >> >>> there should be no dependency on Type's of area configured at OSPF > >> >>> level. > >> >>> > >> >>>2) > >> >>>draft>An OSPF router MAY advertise different capabilities when both > >> >>> NSSA/stub area type 10 LSA(s) and an AS scoped type 11 opaque > >> >>> LSA is advertised. > >> >>>vivek> Capabilities here should map to different TLV's ?? > >> >>> > >> >>>Peter>I guess it can be different TLVs or different content in the > >> >>>same TLV. > >> >>> > >> >>>vivek> Different content in same TLV, advertised in different scoped > >> >>> LSAs (Type 10 and Type 11). Doesnt seems a good idea to me. > >> >>> Any possible scenarios? > >> >>> > >> >>JP - can you take a shot at this? I seem to remember that you had a > >> >>scenario in minde. > >> >> > >> > > >> >Indeed. In the case of TE, there are various cases where a router may > >> >want to advertise a capability with different flooding scopes thus two > >> >different opaque LSAs. For instance, a router may belong to two > >> >different meshes of TE LSPs, one local to its area (RI LSA of Type 10) > >> >one across the routing domain (RI LSA of Type 11). The same TLV > >> >(automesh) is used, with different contents, carried in different LSA > >> >(type 10 and 11). > >> > > >> >Thanks. > >> > > >> >JP. > >> > > >> >>Thanks, > >> >>Acee > >> >> > >> >>> > >> >>>Thanks > >> >>>Vivek > >> >>> > >> >>> > >> >>> > >> >>> > >> >>> > >> >>>On Tue, 07 Dec 2004 Peter Psenak wrote : > >> >>> >Vivek, > >> >>> > > >> >>> >Vivek Dubey wrote: > >> >>> >>Hi, > >> >>> >>Section 2.3: > >> >>> >>draft>TLV flooding scope rules will be specified on a per-TLV > basis > >> >>> >>draft>If a type 11 opaque LSA is chosen, the originating router > >> >>>should > >> >>> >> also advertise type 10 LSA(s) into any attached > NSSA/stub area > >> >>> >> > >> >>> >>vivek) If scope of TLV is defined to be AS (Type 11), why should, > >> >>>the > >> >>> >> originating router advertise type 10 LSA(s) into any > >> >>> >> attached NSSA/stub area ? Idea seems to get the > capabilities > >> >>> >> advertised to NSSA/STUB neighbors of originating > router. But > >> >>> >> what about NSSA/STUB areas attached not to "originating" > >> >>> >> routers?? > >> >>> > > >> >>> >an analogy is when you have an ABR connected to backbone area and > >> >>>NSSA > >> >>> >area and you redistribute routes from some external source. > ABR will > >> >>> >generate Type-5 external LSA, plus it can be configured to > advertise > >> >>> >Type-7 LSA to the NSSA area for the same prefix. > >> >>> >If you have another ASBR somewhere in backbone area, Type-5 > LSAs it > >> >>> >generates will not get propagated to NSSA area. > >> >>> > > >> >>> >> > >> >>> >>draft>An OSPF router MAY advertise different capabilities > when both > >> >>> >> NSSA/stub area type 10 LSA(s) and an AS scoped type 11 > opaque > >> >>> >> LSA is advertised. > >> >>> >>vivek> Capabilities here should map to different TLV's ?? > >> >>> > > >> >>> >I guess it can be different TLVs or different content in the same > >> >>>TLV. > >> >>> > > >> >>> >Peter > >> >>> > > >> >>> >> > >> >>> >>Thanks > >> >>> >>Vivek > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> > >> >>> > >> >>> > >> >>> > >> >> > >> > >> > >> > > > > From owner-ospf@PEACH.EASE.LSOFT.COM Thu Jan 6 12:28:38 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25956 for ; Thu, 6 Jan 2005 12:28:38 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00F38B4D@cherry.ease.lsoft.com>; Thu, 6 Jan 2005 12:28:38 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 52255381 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 6 Jan 2005 12:28:37 -0500 Received: from 64.102.122.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 6 Jan 2005 12:28:37 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 06 Jan 2005 12:40:26 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j06HSYDX004009 for ; Thu, 6 Jan 2005 12:28:34 -0500 (EST) Received: from [10.82.240.191] (rtp-vpn2-191.cisco.com [10.82.240.191]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BEK08937; Thu, 6 Jan 2005 09:28:33 -0800 (PST) User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <41D43402.4060303@iol.unh.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <41DD7541.7070808@cisco.com> Date: Thu, 6 Jan 2005 12:28:33 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: NSSA Test Case To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <41D43402.4060303@iol.unh.edu> Precedence: list Content-Transfer-Encoding: 7bit Mike Cleary wrote: > Hello, > I am trying to set up a test case where two routers advertise static > routes to the same network 3.3.3.0/24 with the same forwarding > address. I need one of the routers to be running in the backbone on > network 10.10.10.0/24 and both of the routers to be running in area 1 > (nssa) on network 10.10.11.0/24. I tried giving the routers a > forwarding address of 10.10.10.141 however one of them does not use > this as the forwarding address since it is not running on network > 10.10.10.0/24. I guess if the P bit is clear there is no harm advertising a type 7 with an address outside the NSSA. I don't believe this case is covered explicitly in RFC 3101. > I also tried advertising a forwarding address of 10.10.11.141 since > they will both be able to advertize this. However the problem is that > I have a third router also running on network 1 and it installs the > route through 10.10.11.141 instead of chosing one of the two routers. This is what it should do. > Does anyone know of a way to force the third router to chose one of > the two others to install the route through? I have attached a > diagram that might be helpful. > Thanks, > ~Mike > > > ------------------------------------------------------------------------ > From owner-ospf@PEACH.EASE.LSOFT.COM Thu Jan 6 12:48:49 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27198 for ; Thu, 6 Jan 2005 12:48:48 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00F38A1B@cherry.ease.lsoft.com>; Thu, 6 Jan 2005 12:48:50 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 52257101 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 6 Jan 2005 12:48:49 -0500 Received: from 132.177.123.82 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 6 Jan 2005 12:48:49 -0500 Received: from iol.unh.edu (scrappy.iol.unh.edu [132.177.118.198]) by io.iol.unh.edu (8.13.2/8.13.2) with ESMTP id j06Hmax8026431; Thu, 6 Jan 2005 12:48:36 -0500 User-Agent: Mozilla/5.0 (X11; U; Linux alpha; en-US; rv:0.9.9) Gecko/20020503 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <41D43402.4060303@iol.unh.edu> <41DD7541.7070808@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-UNH-IOL-MailScanner-Information: Please contact systems@iol.unh.edu for more information X-UNH-IOL-MailScanner: Found to be clean X-UNH-IOL-MailScanner-From: mcleary@iol.unh.edu Message-ID: <41DD7AA7.4080605@iol.unh.edu> Date: Thu, 6 Jan 2005 12:51:35 -0500 Reply-To: Mailing List Sender: Mailing List From: Mike Cleary Subject: Re: NSSA Test Case Comments: cc: Acee Lindem To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hello Acee, I was referring to this quote from RFC 3101 Section 2.4: If an NSSA's border router originates a Type-5 LSA with a forwarding address from the NSSA, it should also originate a Type-7 LSA into the NSSA. If two NSSA routers, both reachable from one another over the NSSA, originate functionally equivalent Type-7 LSAs (i.e., same destination, cost and non-zero forwarding address), then the router having the least preferred LSA should flush its LSA. (See [OSPF] Section 12.4.4.1.) Preference between two Type-7 LSAs is determined by the following tie breaker rules: 1. An LSA with the P-bit set is preferred over one with the P-bit clear. 2. If the P-bit settings are the same, the LSA with the higher router ID is preferred. This leads me to believe that if two routers should be able to originate functionally equivalent Type-7 LSAs with a different P-bit setting and and third NSSA router should prefer one of them then there should be a way to check which is prefered. The method I was using was checking in the routing table of the third router to see which of the other two routers it lists as the gateway. Do you know of another way to observe which of the two routers the third chooses as a gateway for the route? Thanks, ~Mike Acee Lindem wrote: > Mike Cleary wrote: > >> Hello, >> I am trying to set up a test case where two routers advertise static >> routes to the same network 3.3.3.0/24 with the same forwarding >> address. I need one of the routers to be running in the backbone on >> network 10.10.10.0/24 and both of the routers to be running in area 1 >> (nssa) on network 10.10.11.0/24. I tried giving the routers a >> forwarding address of 10.10.10.141 however one of them does not use >> this as the forwarding address since it is not running on network >> 10.10.10.0/24. > > > I guess if the P bit is clear there is no harm advertising a type 7 > with an address > outside the NSSA. I don't believe this case is covered explicitly in > RFC 3101. > >> I also tried advertising a forwarding address of 10.10.11.141 since >> they will both be able to advertize this. However the problem is >> that I have a third router also running on network 1 and it installs >> the route through 10.10.11.141 instead of chosing one of the two >> routers. > > > This is what it should do. > >> Does anyone know of a way to force the third router to chose one of >> the two others to install the route through? I have attached a >> diagram that might be helpful. >> Thanks, >> ~Mike >> >> ------------------------------------------------------------------------ >> > -- ********************************************* Michael Cleary Email: mcleary@iol.unh.edu IPv4 Consortium UNH InterOperability Lab 121 Technology Dr., Suite 2, Durham, NH 03824 Phone: 603-862-3941 http://www.iol.unh.edu ********************************************* From owner-ospf@PEACH.EASE.LSOFT.COM Thu Jan 6 14:16:02 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04444 for ; Thu, 6 Jan 2005 14:16:00 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.00F38C6C@cherry.ease.lsoft.com>; Thu, 6 Jan 2005 14:15:20 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 52264984 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 6 Jan 2005 14:15:10 -0500 Received: from 64.47.51.130 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 6 Jan 2005 14:14:57 -0500 Received: from vpndg ([128.251.10.1] unverified) by exchange.timetra.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 6 Jan 2005 11:14:55 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Importance: Normal X-OriginalArrivalTime: 06 Jan 2005 19:14:55.0958 (UTC) FILETIME=[01CF4F60:01C4F424] Message-ID: Date: Thu, 6 Jan 2005 11:16:35 -0800 Reply-To: Mailing List Sender: Mailing List From: Don Goodspeed Subject: Re: NSSA Test Case Comments: To: Mike Cleary Comments: cc: Acee Lindem To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <41DD7AA7.4080605@iol.unh.edu> Precedence: list Content-Transfer-Encoding: 7bit Mike, What if both the ABR/ASBR router and the NSSA ASBR router both had another shared network in the nssa area 1 (say 10.10.12.0/24) that was OSPF enabled with the next-hop residing on that network? That should cause both ASBR to advertise the same fwding address but the ABR will have the P-bit cleared. Then the DUT should choose a unique next-hop for the route in question. -don -----Original Message----- From: owner-ospf@PEACH.EASE.LSOFT.COM [mailto:owner-ospf@PEACH.EASE.LSOFT.COM]On Behalf Of Mike Cleary Sent: Thursday, January 06, 2005 9:52 AM To: Mailing List Cc: Acee Lindem Subject: Re: NSSA Test Case Hello Acee, I was referring to this quote from RFC 3101 Section 2.4: If an NSSA's border router originates a Type-5 LSA with a forwarding address from the NSSA, it should also originate a Type-7 LSA into the NSSA. If two NSSA routers, both reachable from one another over the NSSA, originate functionally equivalent Type-7 LSAs (i.e., same destination, cost and non-zero forwarding address), then the router having the least preferred LSA should flush its LSA. (See [OSPF] Section 12.4.4.1.) Preference between two Type-7 LSAs is determined by the following tie breaker rules: 1. An LSA with the P-bit set is preferred over one with the P-bit clear. 2. If the P-bit settings are the same, the LSA with the higher router ID is preferred. This leads me to believe that if two routers should be able to originate functionally equivalent Type-7 LSAs with a different P-bit setting and and third NSSA router should prefer one of them then there should be a way to check which is prefered. The method I was using was checking in the routing table of the third router to see which of the other two routers it lists as the gateway. Do you know of another way to observe which of the two routers the third chooses as a gateway for the route? Thanks, ~Mike Acee Lindem wrote: > Mike Cleary wrote: > >> Hello, >> I am trying to set up a test case where two routers advertise static >> routes to the same network 3.3.3.0/24 with the same forwarding >> address. I need one of the routers to be running in the backbone on >> network 10.10.10.0/24 and both of the routers to be running in area 1 >> (nssa) on network 10.10.11.0/24. I tried giving the routers a >> forwarding address of 10.10.10.141 however one of them does not use >> this as the forwarding address since it is not running on network >> 10.10.10.0/24. > > > I guess if the P bit is clear there is no harm advertising a type 7 > with an address > outside the NSSA. I don't believe this case is covered explicitly in > RFC 3101. > >> I also tried advertising a forwarding address of 10.10.11.141 since >> they will both be able to advertize this. However the problem is >> that I have a third router also running on network 1 and it installs >> the route through 10.10.11.141 instead of chosing one of the two >> routers. > > > This is what it should do. > >> Does anyone know of a way to force the third router to chose one of >> the two others to install the route through? I have attached a >> diagram that might be helpful. >> Thanks, >> ~Mike >> >> ------------------------------------------------------------------------ >> > -- ********************************************* Michael Cleary Email: mcleary@iol.unh.edu IPv4 Consortium UNH InterOperability Lab 121 Technology Dr., Suite 2, Durham, NH 03824 Phone: 603-862-3941 http://www.iol.unh.edu ********************************************* From owner-ospf@PEACH.EASE.LSOFT.COM Thu Jan 6 21:37:44 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19794 for ; Thu, 6 Jan 2005 21:37:44 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00F3939B@cherry.ease.lsoft.com>; Thu, 6 Jan 2005 21:37:44 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 52305553 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 6 Jan 2005 21:37:40 -0500 Received: from 131.228.20.26 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 6 Jan 2005 21:37:40 -0500 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j072bXi27184 for ; Fri, 7 Jan 2005 04:37:37 +0200 (EET) X-Scanned: Fri, 7 Jan 2005 04:35:15 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id j072ZFnN015231 for ; Fri, 7 Jan 2005 04:35:15 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00zw6BPe; Fri, 07 Jan 2005 04:35:14 EET Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j072Z8U01825 for ; Fri, 7 Jan 2005 04:35:09 +0200 (EET) Received: from mvebe001.NOE.Nokia.com ([172.18.140.37]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 6 Jan 2005 20:33:25 -0600 Received: mvebe001 172.18.140.37 from 172.19.66.99 172.19.66.99 via HTTP with MS-WebStorage 6.0.6249 Received: from mvwsipd90027 by mvebe001; 06 Jan 2005 18:33:24 -0800 References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-1.Linox.1) X-OriginalArrivalTime: 07 Jan 2005 02:33:25.0904 (UTC) FILETIME=[43C27900:01C4F461] Message-ID: <1105065203.22854.54.camel@mvwsipd90027> Date: Thu, 6 Jan 2005 18:33:24 -0800 Reply-To: Mailing List Sender: Mailing List From: Suresh Melam Subject: Re: draft-ietf-ospf-ospfv3-auth-06.txt Ready for IESG review To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit Hi Vishwas, Comments inline, regards, - suresh > We wanted to keep the section general without making it > specific to ESP or AH. So when we say "Null encryption with > MD5 authentication", it could be used either with ESP or > with AH. Do we need to add more text to make it clearer? > Do you any have specific changes in mind ? VM> I do not agree when you say NULL encryption it can refer to AH, I think it means only ESP. NULL Encryption can be treated equivalent to any other encryption algorithm atleast that is what I know of. suresh> AH & ESP differ in the protection provided to different fields of the packet. In this section of the draft, we were interested in comparing the difficulty of breaking the keys, but not really in the attacks once the keying material is compromised. Do you see any difference in terms of difficulty in breaking the keys for "NULL encryption with MD5 auth with ESP" and "MD5 authentication with AH"? > Well, the draft does not recommend using DES either. We just > wanted to compare some non-null encryption schemes with null > encryption schemes and we chose des, 3des and AES. The draft > mandates the usage of AES so it is inline with the other > IPsec drafts. VM> I do not think we should use examples of schemes, which have been mentioned as "SHOULD NOT" by the IETF/NIST. Suresh> We are not a fan of DES either for obvious reasons. But as we wanted to start with the weakest algorithm, we started with DES. We wouldn't have to mention DES at all, had IETF/NIST suggested DES as "MUST NOT". > All the IPsec implementations that support AES for IPsec > MUST support 128 bit key size (RFC 3602). So are we not > ok without mentioning the key sizes in this draft and just > referring to 3602? VM> Mukesh I am comming more from the point of view of draft-ietf-ipsec-esp-ah-algorithms-02.txt, which also seems to specify the key size. IT is the document for ESP/AH specifying mandatory protocols. > > We had taken this approach in previous revs (04, I guess) > but Security ADs (Russ) wanted to have at least one algorithm > required by this draft just to make sure that the > implementations were interoperable. We added AES/SHA1 > as mandatory as suggested by Russ. VM> I guess I should have been clearer. I agree and infact had asked for the same thing in my previous review. I am asking is that we have another companion draft specifying the mandatory algorithms as is done for IPSec/IKE etc. It helps becuase as and when we move forward and algorithms change we just need to change that document rather then the whole IPSec for OSPF document. Suresh> IMHO, a companion draft for just this will be an overkill. Mukesh and I discussed this again and we agree that referring to the IPsec algorithm draft should be the better way to go. We also looked at the 04 version and realized that the related text was not clear in that version. We will discuss this with Russ again and see if we can come up with some text to satisfy us all :) > "There are no known threats of replaying these type of packets." > with > "There are no known threats of replaying these type of packets > except that the receiving router will have to spend some resources > to handle these packets." VM> I agree, however I think one more point we miss is that, when adjacencies are not full the link is not used for transit data traffic. In the sense its a clear DoS attack where we can make the link unusable. I have already told the OSPF Vulnerabilities draft authors about the same. This also causes transient loops because of changing topologies. Suresh> What about the following: "Replaying these type of packets can make the router spend some resources. Also when the OSPF adjacency is not FULL, replaying database description packets can cause disruption in forming the adjacency." > Sorry ! I do not understand which default/supported values > you are talking about here :( Could you please be a little > more specific? VM> As you stated that Russ specified(and I totally agree) some minimal options for implementations to interoperate is necessary(and I think the primary aim of this draft). We should specify if we are using options Extended Sequence Numbers(ESN) or not at the minimum etc. The reason is the same for DSCP, check the recent discussion on http://www1.ietf.org/mail-archive/web/ipsec/current/index.html I had with Steve Kent and the changes being made to the IPSec security architecture document because of that. Suresh> We are using manual keys here so the sequence numbers will be ignored. So do we really need to worry about ESN ? VM> Mukesh, I also noted that recommendation of changes for the MIB is not made in the draft Would there be any changes to the MIB? Suresh> Is it customary to add a "MIB recommendations" section? In any case, we should work closely with the MIB draft authors to update the MIB entries to include the security details. From owner-ospf@PEACH.EASE.LSOFT.COM Thu Jan 6 23:18:20 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26134 for ; Thu, 6 Jan 2005 23:18:20 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.00F397A1@cherry.ease.lsoft.com>; Thu, 6 Jan 2005 23:18:20 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 52314924 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 6 Jan 2005 23:18:19 -0500 Received: from 63.197.255.158 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 6 Jan 2005 23:18:19 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: draft-ietf-ospf-ospfv3-auth-06.txt Ready for IESG review thread-index: AcT0YyKUKN+2jhfMQtG30BwiBt67fgADHBMg Message-ID: Date: Thu, 6 Jan 2005 20:26:09 -0800 Reply-To: Mailing List Sender: Mailing List From: Vishwas Manral Subject: Re: draft-ietf-ospf-ospfv3-auth-06.txt Ready for IESG review To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Hi Suresh, Suresh> Do you see any difference in terms of difficulty in breaking the keys for "NULL encryption with MD5 auth with ESP" and "MD5 authentication with AH"? VM> I do not think you talk about encryption at all when you talk about AH. If you check the documents I have pointed to carefully, you will see NULL Encryption is a special case of encryption when encryption is not used. Suresh> We are not a fan of DES either for obvious reasons. But as we wanted to start with the weakest algorithm, we started with DES. We wouldn't have to mention DES at all, had IETF/NIST=20 suggested DES as "MUST NOT". VM> I still don't see a reason why we should talk about DES at all. Suresh> Mukesh and I discussed this again and we agree that referring to the IPsec algorithm draft should be the better way to go. =20 VM> Also not for the authentication you have given the key length and for Encryption you have not(so there is anyway a case of inconsistency). Suresh> What about the following: "Replaying these type of packets can make the router spend some resources. Also when the OSPF adjacency is not FULL, replaying=20 database description packets can cause disruption in forming the adjacency." VM> Its not just forming the adjacency Suresh but the link becoming unusable for transit traffic (DoS). In my view you should just refer to the vulnerabilities draft and probably put a sentence like the above. Suresh> We are using manual keys here so the sequence numbers will be ignored. So do we really need to worry about ESN? VM> You are right. However I think the aim of the draft is to specify how we should use IPSec (guidelines) as well as specify the default behavior(Maybe for all optional parameters we should specify this). Thanks, Vishwas=20 -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Suresh Melam Sent: Friday, January 07, 2005 8:03 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: draft-ietf-ospf-ospfv3-auth-06.txt Ready for IESG review Hi Vishwas,=20 Comments inline,=20 regards, - suresh > We wanted to keep the section general without making it=20 > specific to ESP or AH. So when we say "Null encryption with=20 > MD5 authentication", it could be used either with ESP or=20 > with AH. Do we need to add more text to make it clearer?=20 > Do you any have specific changes in mind ?=20 VM> I do not agree when you say NULL encryption it can refer to AH, I think it means only ESP. NULL Encryption can be treated equivalent to any other encryption algorithm atleast that is what I know of.=20 suresh> AH & ESP differ in the protection provided to different fields of the packet. In this section of the draft, we were interested in comparing the difficulty of breaking the keys, but not really in the attacks once the keying material is compromised.=20 Do you see any difference in terms of difficulty in breaking the keys for "NULL encryption with MD5 auth with ESP" and "MD5 authentication with AH"?=20 > Well, the draft does not recommend using DES either. We just=20 > wanted to compare some non-null encryption schemes with null=20 > encryption schemes and we chose des, 3des and AES. The draft=20 > mandates the usage of AES so it is inline with the other=20 > IPsec drafts.=20 VM> I do not think we should use examples of schemes, which have been=20 mentioned as "SHOULD NOT" by the IETF/NIST.=20 Suresh> We are not a fan of DES either for obvious reasons. But as we wanted to start with the weakest algorithm, we started with DES. We wouldn't have to mention DES at all, had IETF/NIST=20 suggested DES as "MUST NOT". > All the IPsec implementations that support AES for IPsec=20 > MUST support 128 bit key size (RFC 3602). So are we not=20 > ok without mentioning the key sizes in this draft and just=20 > referring to 3602?=20 VM> Mukesh I am comming more from the point of view of=20 draft-ietf-ipsec-esp-ah-algorithms-02.txt, which also seems=20 to specify the key size. IT is the document for ESP/AH=20 specifying mandatory protocols.=20 > > We had taken this approach in previous revs (04, I guess)=20 > but Security ADs (Russ) wanted to have at least one algorithm=20 > required by this draft just to make sure that the=20 > implementations were interoperable. We added AES/SHA1=20 > as mandatory as suggested by Russ.=20 VM> I guess I should have been clearer. I agree and infact had asked for the same thing in my previous review. I am asking is that we have another companion draft specifying the mandatory algorithms as is done for IPSec/IKE etc. It helps becuase as and when we move forward and algorithms change we just need to change that document rather then the whole IPSec for OSPF document.=20 Suresh> IMHO, a companion draft for just this will be an overkill. Mukesh and I discussed this again and we agree that referring to the IPsec algorithm draft should be the better way to go. We also looked at the 04 version and realized that the related text was not clear in that version. We will discuss this with Russ again and see if we can come up with some text to satisfy us all :) > "There are no known threats of replaying these type of packets." > with=20 > "There are no known threats of replaying these type of packets=20 > except that the receiving router will have to spend some resources=20 > to handle these packets."=20 VM> I agree, however I think one more point we miss is that, when=20 adjacencies are not full the link is not used for transit data traffic. In the sense its a clear DoS attack where we can make the link unusable. I have already told the OSPF Vulnerabilities draft authors about the same. This also causes transient loops because of changing topologies.=20 Suresh> What about the following: "Replaying these type of packets can make the router spend some resources. Also when the OSPF adjacency is not FULL, replaying=20 database description packets can cause disruption in forming the adjacency." > Sorry ! I do not understand which default/supported values=20 > you are talking about here :( Could you please be a little=20 > more specific?=20 VM> As you stated that Russ specified(and I totally agree) some minimal options for implementations to interoperate is necessary(and I think the primary aim of this draft). We should specify if we are using options Extended Sequence Numbers(ESN) or not at the minimum etc. The reason is the same for DSCP, check the recent discussion on=20 http://www1.ietf.org/mail-archive/web/ipsec/current/index.html I had with Steve Kent and the changes being made to the IPSec security architecture document because of that.=20 Suresh> We are using manual keys here so the sequence numbers will be ignored. So do we really need to worry about ESN ? VM> Mukesh, I also noted that recommendation of changes for the MIB is not made in the draft Would there be any changes to the MIB?=20 Suresh> Is it customary to add a "MIB recommendations" section? In any case, we should work closely with the MIB draft authors to update the MIB entries to include the security details. From owner-ospf@PEACH.EASE.LSOFT.COM Fri Jan 7 02:52:30 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23078 for ; Fri, 7 Jan 2005 02:52:28 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00F39D42@cherry.ease.lsoft.com>; Fri, 7 Jan 2005 2:52:21 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 52328525 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 7 Jan 2005 02:52:20 -0500 Received: from 131.228.20.22 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 7 Jan 2005 02:52:19 -0500 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j077qCs15091 for ; Fri, 7 Jan 2005 09:52:14 +0200 (EET) X-Scanned: Fri, 7 Jan 2005 09:50:44 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id j077oi9h027967 for ; Fri, 7 Jan 2005 09:50:44 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00NDaoMO; Fri, 07 Jan 2005 09:50:42 EET Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j077ofU22623 for ; Fri, 7 Jan 2005 09:50:41 +0200 (EET) Received: from daebe009.NOE.Nokia.com ([10.241.35.109]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 7 Jan 2005 01:50:39 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: draft-ietf-ospf-ospfv3-auth-06.txt Ready for IESG review thread-index: AcT0YyKUKN+2jhfMQtG30BwiBt67fgADHBMgAAaItqA= X-OriginalArrivalTime: 07 Jan 2005 07:50:39.0936 (UTC) FILETIME=[94ED4400:01C4F48D] Message-ID: <8D260779A766FB4A9C1739A476F84FA401F79BAC@daebe009.americas.nokia.com> Date: Fri, 7 Jan 2005 01:50:40 -0600 Reply-To: Mailing List Sender: Mailing List From: Mukesh Gupta Subject: Re: draft-ietf-ospf-ospfv3-auth-06.txt Ready for IESG review To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Vishwas, Comments inline.. > VM> I do not think you talk about encryption at all when you=20 > talk about > AH. If you check the documents I have pointed to carefully,=20 > you will see > NULL Encryption is a special case of encryption when encryption is not > used. Would it make more sense if we change the text "NULL encryption"=20 to "NULL encryption (for ESP) or no encryption (for AH)" ? > Suresh> We are not a fan of DES either for obvious reasons. But as we > wanted to start with the weakest algorithm, we started with DES. We > wouldn't have to mention DES at all, had IETF/NIST=20 > suggested DES as "MUST NOT". > VM> I still don't see a reason why we should talk about DES at all. I still don't understand why we can't use DES as an example of a weak encryption algorithm. =20 I would like to hear others' opnion about this ? Acee? > Suresh> Mukesh and I discussed this again and we agree that=20 > referring to > the IPsec algorithm draft should be the better way to go. =20 > VM> Also not for the authentication you have given the key length and > for Encryption you have not(so there is anyway a case of=20 > inconsistency). Yeah but this will be fixed too if we didn't mention any algorithm and just pointed to the madatory to implement algos. Right ? > Suresh> What about the following: > "Replaying these type of packets can make the router spend some > resources. Also when the OSPF adjacency is not FULL, replaying=20 > database description packets can cause disruption in forming the > adjacency." > VM> Its not just forming the adjacency Suresh but the link becoming > unusable for transit traffic (DoS). In my view you should=20 > just refer to > the vulnerabilities draft and probably put a sentence like the above. We do refer to the vulnerabilities draft after the brief discussion of the replay vulnerabilities.. So are you ok with putting the text proposed above and then referring to the vulerabilities draft ? > VM> You are right. However I think the aim of the draft is to specify > how we should use IPSec (guidelines) as well as specify the default > behavior(Maybe for all optional parameters we should specify this). You are right. The aim of this draft is to specify how OSPFv3 should use IPsec but I still fail to understand why we need to specify things that are not related or exposed to OSPF :( What exactly do you want to specify about ESN? Do we want to say that there is no impact of the usage of ESN by the underlying IPsec implementation on OSPFv3 security because sequence numbers are ignored while manual keys are used ? Regards Mukesh From owner-ospf@PEACH.EASE.LSOFT.COM Fri Jan 7 03:40:12 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25762 for ; Fri, 7 Jan 2005 03:40:12 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00F39E57@cherry.ease.lsoft.com>; Fri, 7 Jan 2005 3:40:12 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 52329770 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 7 Jan 2005 03:40:11 -0500 Received: from 63.197.255.158 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 7 Jan 2005 03:40:11 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: draft-ietf-ospf-ospfv3-auth-06.txt Ready for IESG review thread-index: AcT0YyKUKN+2jhfMQtG30BwiBt67fgADHBMgAAaItqAAArMHMA== Message-ID: Date: Fri, 7 Jan 2005 00:48:04 -0800 Reply-To: Mailing List Sender: Mailing List From: Vishwas Manral Subject: Re: draft-ietf-ospf-ospfv3-auth-06.txt Ready for IESG review To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Hi Mukesh, -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Mukesh Gupta Sent: Friday, January 07, 2005 1:21 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: draft-ietf-ospf-ospfv3-auth-06.txt Ready for IESG review Vishwas, Comments inline.. > VM> I do not think you talk about encryption at all when you=20 > talk about > AH. If you check the documents I have pointed to carefully,=20 > you will see > NULL Encryption is a special case of encryption when encryption is not > used. Would it make more sense if we change the text "NULL encryption"=20 to "NULL encryption (for ESP) or no encryption (for AH)" ? VM> OK. > Suresh> We are not a fan of DES either for obvious reasons. But as we > wanted to start with the weakest algorithm, we started with DES. We > wouldn't have to mention DES at all, had IETF/NIST=20 > suggested DES as "MUST NOT". > VM> I still don't see a reason why we should talk about DES at all. I still don't understand why we can't use DES as an example of a weak encryption algorithm. =20 I would like to hear others' opnion about this ? Acee? VM> I think examples should not be given of protocols which are on the "SHOULD NOT" list of IETF/NIST. > Suresh> Mukesh and I discussed this again and we agree that=20 > referring to > the IPsec algorithm draft should be the better way to go. =20 > VM> Also not for the authentication you have given the key length and > for Encryption you have not(so there is anyway a case of=20 > inconsistency). Yeah but this will be fixed too if we didn't mention any algorithm and just pointed to the madatory to implement algos. Right ? VM> Yes, however I think we should be specifying a default algorithm for OSPF(or are you saying you are not specifying any algorithms instead just directly pointing to the ESP/AH algorithms document). > Suresh> What about the following: > "Replaying these type of packets can make the router spend some > resources. Also when the OSPF adjacency is not FULL, replaying=20 > database description packets can cause disruption in forming the > adjacency." > VM> Its not just forming the adjacency Suresh but the link becoming > unusable for transit traffic (DoS). In my view you should=20 > just refer to > the vulnerabilities draft and probably put a sentence like the above. We do refer to the vulnerabilities draft after the brief discussion of the replay vulnerabilities.. So are you ok with putting the text proposed above and then referring to the vulerabilities draft ? VM> As long as you put the text for the DoS case too, I am ok. Else let us directly point to the vulnerabilities draft without mentioning cases. > VM> You are right. However I think the aim of the draft is to specify > how we should use IPSec (guidelines) as well as specify the default > behavior(Maybe for all optional parameters we should specify this). You are right. The aim of this draft is to specify how OSPFv3 should use IPsec but I still fail to understand why we need to specify things that are not related or exposed to OSPF :( What exactly do you want to specify about ESN? Do we want to say that there is no impact of the usage of ESN by the underlying IPsec implementation on OSPFv3 security because sequence numbers are ignored while manual keys are used ? VM> As Suresh rightly said ESN does not make sense with manual keying. So it is not about ESN alone. DSCP was one example I had pointed out too. Thanks and sorry for bothering you, Vishwas From owner-ospf@PEACH.EASE.LSOFT.COM Fri Jan 7 10:48:58 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22101 for ; Fri, 7 Jan 2005 10:48:56 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00F3A4F1@cherry.ease.lsoft.com>; Fri, 7 Jan 2005 10:48:52 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 52393260 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 7 Jan 2005 10:48:50 -0500 Received: from 61.144.161.55 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 7 Jan 2005 10:38:50 -0500 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0I9Y0037LE3Q7I@szxga03-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Fri, 07 Jan 2005 23:38:14 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0I9Y009ISE3QV2@szxga03-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Fri, 07 Jan 2005 23:38:14 +0800 (CST) Received: from Jayalakshmig ([10.18.4.193]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0I9Y003MIE9YQZ@szxml01-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Fri, 07 Jan 2005 23:42:00 +0800 (CST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Message-ID: <000001c4f4cf$e2f60c80$0100a8c0@in.huawei.com> Date: Fri, 7 Jan 2005 21:15:16 +0530 Reply-To: Mailing List Sender: Mailing List From: Jayalakshmi G Organization: HUAWEI Subject: Next-hop calculation To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7BIT Hi all, I have a doubt in calculating next-hop for network in OSPFv3. Consider my topology, RTA |e0 | RTB---------------- RTC e1 e1 RTB e1's interface prefix 3001::3 / 64 RTC e1's prefix 3001::9 / 64 and RTA e0's interface prefix 4000::6 / 64 For next hop calculation: RFC 2740 explains the difference only in calculation for Router and rest will be same as 2328. RFC 2328 states: "If the destination is a directly connected network, or a router which connects to the calculating router via a point-to-point interface, no next hop IP address is required." Above lines say, if we are calculating for a directly connected network then we don't need any next hop. But, in my topology RTA's interface prefix is different from the network 3001:: /64. So, according to RFC 3001::/64 would seem as directly connected and would have no next hop. Actually its next hops should be RTB's and RTC's link local addresses. So, any suggestions as to how should I find the correct next-hops? Thanks & Regards, Jaya From owner-ospf@PEACH.EASE.LSOFT.COM Fri Jan 7 11:32:20 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24927 for ; Fri, 7 Jan 2005 11:32:16 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.00F3A6CB@cherry.ease.lsoft.com>; Fri, 7 Jan 2005 11:32:16 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 52397954 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 7 Jan 2005 11:32:15 -0500 Received: from 203.199.83.246 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 7 Jan 2005 11:32:14 -0500 Received: (qmail 15237 invoked by uid 510); 7 Jan 2005 16:33:38 -0000 Received: from unknown (203.126.136.223) by rediffmail.com via HTTP; 07 jan 2005 16:33:38 -0000 MIME-Version: 1.0 Content-type: multipart/alternative; boundary="Next_1105115618---0-203.199.83.246-15230" Message-ID: <20050107163338.15236.qmail@webmail35.rediffmail.com> Date: Fri, 7 Jan 2005 16:33:38 -0000 Reply-To: Mailing List Sender: Mailing List From: Vivek Dubey Subject: Re: draft-ietf-ospf-cap-04.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This is a multipart mime message --Next_1105115618---0-203.199.83.246-15230 Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Acee,=0A =A0=0A>If the function corresponding to the capability is also = scoped at the >area level,then it makes sense to only advertise it at that = level. I =0A>could add a sentence to that effect.=0A=0ATakes care of my con= cern.=0A=0AThanks=0AVivek=0A=0A=0A=0A=0AOn Thu, 06 Jan 2005 Acee Lindem wro= te :=0A>Hi Vivek,=0A>See inline.=0A>=0A>Vivek Dubey wrote:=0A>=0A>>Hi Acee,= =0A>>Sorry for delayed response.=0A>>=0A>>My thoughts:=0A>>- Save OSPF capa= bilities (TLV 1), other capabilities/TLV (like TLV 2=0A>> etc), mostly wo= uld be opaque to OSPF, i.e depending on required=0A>> distribution in rou= ting domain, how they are distributed (OSPF=0A>> flooding scopes)is decid= ed. Dont see why for such TLVs content be=0A>> affected by flooding scope= .=0A>>=0A>In most cases they will. However, we want to allow for situations= =0A>where a capability is enabled in one area but not another.=0A>=0A>> = That is, taking TLV or sub-tlv, for a particular router,=0A>> it should r= epresent consistent view across different flooding=0A>> scopes.=0A>>=0A>>= 1)Router X is connected to Router A(through normal Areas - A1 and A2)=0A>>= =0A>> Assume there is TLV TV1 (opaque to OSPF), having bits (B1, B2)=0A>>= representing different capabilities.=0A>>=0A>> Router A capabilities f= looded (based on policy/configuration):=0A>> Area A1 (Type 10): TV1 - Bit= s(1,0)=0A>> Area A2 (Type 10): TV1 - Bits(0,1)=0A>>=0A>> Now at Router = X, one will maintain some kind of centalized database=0A>> for advertised= opaque capabilities of Router A (these should not be=0A>> associated wit= h OSPF AREA as TLV itself is opaque to OSPF).=0A>>=0A>> Router X database= : Router A Capability: TV1 (1,1)=0A>>=0A>> Dont see any benefit of having= different TLV contents in different=0A>> areas in such cases.=0A>>=0A>If= the function corresponding to the capability is also scoped at the area le= vel,=0A>then it makes sense to only advertise it at that level. I could add= a sentence to=0A>that effect.=0A>=0A>>=0A>>2)Router A capabilities flooded= (based on policy/configuration):=0A>> Area A1 (Type 10): TV1 - Bits(1,0)= =0A>> Area A2 (Type 10): TV1 - Bits(0,1)=0A>>=0A>> Router X database: R= outer A Capability: TV1 (1,1)=0A>>=0A>> Next Area A1 adjacency is lost be= tween Router A and Router X.=0A>> Resulting in flushing of RI OPQ LSA in = that area.=0A>>=0A>LSAs aren't flushed when an adjacency goes down but it= =0A>shouldn't be used if the corresponding router is unreachable.=0A>Eventu= ally, it will age out.=0A>=0A>>=0A>> What should than Router X database c= ontain ???=0A>>=0A>> Router X database: Router A Capability: TV1 (1,1)=0A= >> OR=0A>> Router X database: Router A Capability: TV1 (0,1)=0A>>=0A>= Router X's area A2 database will contain the latter. The capability=0A>LSA = for Router A in area A1 database is no longer applicable since=0A>Router A = is unreachable.=0A>=0A>>=0A>>-Vivek =0A>>=0A>>On Sun, 19 Dec 2004 Acee Li= ndem wrote :=0A>> >Hi Vivek,=0A>> >Independent of the capabilities LSA appl= ication, I don't see why a=0A>> >router couldn't have different capabilitie= s in different areas dependent=0A>> >on configuration or policy. What do yo= u see wrong with this?=0A>> >=0A>> >Speaking as work group member,=0A>> >Ac= ee=0A>> >=0A>> >Vivek Dubey wrote:=0A>> >=0A>> >>JP,=0A>> >>Comments inline= d:=0A>> >>=0A>> >>Indeed. In the case of TE, there are various cases where = a router may=0A>> >>want to advertise a capability with different flooding = scopes thus two=0A>> >>different opaque LSAs. For instance, a router may be= long to two=0A>> >>different meshes of TE LSPs, one local to its area (RI L= SA of Type 10)=0A>> >>one across the routing domain (RI LSA of Type 11).=0A= >> >>=0A>> >>vivek> If i understand correctly you are referring to the case= when router has attached NSSA/STUB area's, otherwise RI LSA of Type 11, wo= uld suffice.=0A>> >>=0A>> >>The same TLV (automesh) is used, with different= contents, carried in different LSA (type 10 and 11).=0A>> >>=0A>> >>vivek>= Why same TLV is required to carry different contents in different scoped L= SAs. What if same contents are carried in both Type 10 and Type 11 RI opaqu= e LSAs. Are we intending to hide some information across different OSPF flo= oding scopes ? Since router's capability is independent of "Flooding Scopes= ", that should not be the case.=0A>> >>=0A>> >>Thanks=0A>> >>Vivek=0A>> >>= =0A>> >>=0A>> >>=0A>> >>=0A>> >>On Wed, 08 Dec 2004 JP Vasseur wrote :=0A>>= >> >Hi Vivek,=0A>> >> >=0A>> >> >On Dec 7, 2004, at 5:16 PM, Acee Lindem w= rote:=0A>> >> >=0A>> >> >>Hi Vivek,=0A>> >> >>=0A>> >> >>=0A>> >> >>Vivek D= ubey wrote:=0A>> >> >>=0A>> >> >>>Peter,=0A>> >> >>>=0A>> >> >>>1) In case = of ABR analogy, the information was directly relevant to=0A>> >> >>> OSPF = routing and even than it was provided as configuration option,=0A>> >> >>> = not a "should" condition.=0A>> >> >>>=0A>> >> >>I think the configuration = option is implementation specific. Although=0A>> >> >>it is=0A>> >> >>not c= overed explicitly I think RFC 3103 implies an ABR will=0A>> >> >>redistribu= te=0A>> >> >>into both attached NSSAs and regular areas.=0A>> >> >>=0A>> >>= >>=0A>> >> >>>=0A>> >> >>> Here, OSPF RI Opaque LSA is used for both:=0A>= > >> >>> a) Advertising router's OSPF capabilities (TLV 1)=0A>> >> >>> b)= Capablities Opaque to OSPF (Any future TLVs defined)=0A>> >> >>>=0A>> >> >= >> And since flooding scope is per TLV and depends on local policy,=0A>> >= > >>> there should be no dependency on Type's of area configured at OSPF= =0A>> >> >>> level.=0A>> >> >>>=0A>> >> >>>2)=0A>> >> >>>draft>An OSPF rou= ter MAY advertise different capabilities when both=0A>> >> >>> NSSA/st= ub area type 10 LSA(s) and an AS scoped type 11 opaque=0A>> >> >>> LSA= is advertised.=0A>> >> >>>vivek> Capabilities here should map to different= TLV's ??=0A>> >> >>>=0A>> >> >>>Peter>I guess it can be different TLVs or = different content in the=0A>> >> >>>same TLV.=0A>> >> >>>=0A>> >> >>>vivek>= Different content in same TLV, advertised in different scoped=0A>> >> >>> = LSAs (Type 10 and Type 11). Doesnt seems a good idea to me.=0A>> >> >>= > Any possible scenarios?=0A>> >> >>>=0A>> >> >>JP - can you take a sh= ot at this? I seem to remember that you had a=0A>> >> >>scenario in minde.= =0A>> >> >>=0A>> >> >=0A>> >> >Indeed. In the case of TE, there are various= cases where a router may=0A>> >> >want to advertise a capability with diff= erent flooding scopes thus two=0A>> >> >different opaque LSAs. For instance= , a router may belong to two=0A>> >> >different meshes of TE LSPs, one loca= l to its area (RI LSA of Type 10)=0A>> >> >one across the routing domain (R= I LSA of Type 11). The same TLV=0A>> >> >(automesh) is used, with different= contents, carried in different LSA=0A>> >> >(type 10 and 11).=0A>> >> >=0A= >> >> >Thanks.=0A>> >> >=0A>> >> >JP.=0A>> >> >=0A>> >> >>Thanks,=0A>> >> >= >Acee=0A>> >> >>=0A>> >> >>>=0A>> >> >>>Thanks=0A>> >> >>>Vivek=0A>> >> >>>= =0A>> >> >>>=0A>> >> >>>=0A>> >> >>>=0A>> >> >>>=0A>> >> >>>On Tue, 07 Dec = 2004 Peter Psenak wrote :=0A>> >> >>> >Vivek,=0A>> >> >>> >=0A>> >> >>> >Vi= vek Dubey wrote:=0A>> >> >>> >>Hi,=0A>> >> >>> >>Section 2.3:=0A>> >> >>> >= >draft>TLV flooding scope rules will be specified on a per-TLV basis=0A>> >= > >>> >>draft>If a type 11 opaque LSA is chosen, the originating router=0A>= > >> >>>should=0A>> >> >>> >> also advertise type 10 LSA(s) into any a= ttached NSSA/stub area=0A>> >> >>> >>=0A>> >> >>> >>vivek) If scope of TLV = is defined to be AS (Type 11), why should,=0A>> >> >>>the=0A>> >> >>> >> = originating router advertise type 10 LSA(s) into any=0A>> >> >>> >> = attached NSSA/stub area ? Idea seems to get the capabilities=0A>> >> >>> >= > advertised to NSSA/STUB neighbors of originating router. But=0A>> >>= >>> >> what about NSSA/STUB areas attached not to "originating"=0A>> = >> >>> >> routers??=0A>> >> >>> >=0A>> >> >>> >an analogy is when you = have an ABR connected to backbone area and=0A>> >> >>>NSSA=0A>> >> >>> >are= a and you redistribute routes from some external source. ABR will=0A>> >> >= >> >generate Type-5 external LSA, plus it can be configured to advertise=0A= >> >> >>> >Type-7 LSA to the NSSA area for the same prefix.=0A>> >> >>> >If= you have another ASBR somewhere in backbone area, Type-5 LSAs it=0A>> >> >= >> >generates will not get propagated to NSSA area.=0A>> >> >>> >=0A>> >> >= >> >>=0A>> >> >>> >>draft>An OSPF router MAY advertise different capabiliti= es when both=0A>> >> >>> >> NSSA/stub area type 10 LSA(s) and an AS sc= oped type 11 opaque=0A>> >> >>> >> LSA is advertised.=0A>> >> >>> >>vi= vek> Capabilities here should map to different TLV's ??=0A>> >> >>> >=0A>> = >> >>> >I guess it can be different TLVs or different content in the same= =0A>> >> >>>TLV.=0A>> >> >>> >=0A>> >> >>> >Peter=0A>> >> >>> >=0A>> >> >>>= >>=0A>> >> >>> >>Thanks=0A>> >> >>> >>Vivek=0A>> >> >>> >>=0A>> >> >>> >>= =0A>> >> >>> >>=0A>> >> >>> >>=0A>> >> >>>=0A>> >> >>>=0A>> >> >>>=0A>> >> >>>=0A>> >> >>=0A>> >>=0A>> >>=0A>> >>=0A>>=0A>>=0A>>=0A>>=0A --Next_1105115618---0-203.199.83.246-15230 Content-type: text/html; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

=0AHi Acee,
=0A 
=0A>If the function corresponding to the= capability is also scoped at the >area level,then it makes sense to onl= y advertise it at that level. I
=0A>could add a sentence to that eff= ect.
=0A
=0ATakes care of my concern.
=0A
=0AThanks
=0AVivek=
=0A
=0A
=0A
=0A
=0AOn Thu, 06 Jan 2005 Acee Lindem wrote :<= BR>=0A>Hi Vivek,
=0A>See inline.
=0A>
=0A>Vivek Dubey = wrote:
=0A>
=0A>>Hi Acee,
=0A>>Sorry for delayed re= sponse.
=0A>>
=0A>>My thoughts:
=0A>>- Save OSPF= capabilities (TLV 1), other capabilities/TLV (like TLV 2
=0A>>&nb= sp; etc), mostly would be opaque to OSPF, i.e depending on required
=0A= >>  distribution in routing domain, how they are distributed (O= SPF
=0A>>  flooding scopes)is decided. Dont see why for such= TLVs content be
=0A>>  affected by flooding scope.
=0A&g= t;>
=0A>In most cases they will. However, we want to allow for sit= uations
=0A>where a capability is enabled in one area but not another= .
=0A>
=0A>>    That is, taking TLV or sub-tlv, fo= r a particular router,
=0A>>  it should represent consistent= view across different flooding
=0A>>  scopes.
=0A>>= ;
=0A>>1)Router X is connected to Router A(through normal Areas - = A1 and A2)
=0A>>
=0A>>  Assume there is TLV TV1 (op= aque to OSPF), having bits (B1, B2)
=0A>>  representing diff= erent capabilities.
=0A>>
=0A>>  Router A capabilit= ies flooded (based on policy/configuration):
=0A>>  Area A1 = (Type 10): TV1 - Bits(1,0)
=0A>>  Area A2 (Type 10): TV1 - B= its(0,1)
=0A>>
=0A>>  Now at Router X, one will mai= ntain some kind of centalized database
=0A>>  for advertised= opaque capabilities of Router A (these should not be
=0A>>  = associated with OSPF AREA as TLV itself is opaque to OSPF).
=0A>>=
=0A>>  Router X database: Router A Capability: TV1 (1,1)=0A>>
=0A>>  Dont see any benefit of having different= TLV contents in different
=0A>>  areas in such cases.
= =0A>>
=0A>If the function corresponding to the capability is al= so scoped at the area level,
=0A>then it makes sense to only advertis= e it at that level. I could add a sentence to
=0A>that effect.
=0A= >
=0A>>
=0A>>2)Router A capabilities flooded (based on= policy/configuration):
=0A>>  Area A1 (Type 10): TV1 - Bits= (1,0)
=0A>>  Area A2 (Type 10): TV1 - Bits(0,1)
=0A>&g= t;
=0A>>  Router X database: Router A Capability: TV1 (1,1)<= BR>=0A>>
=0A>>  Next Area A1 adjacency is lost between= Router A and Router X.
=0A>>  Resulting in flushing of RI O= PQ LSA in that area.
=0A>>
=0A>LSAs aren't flushed when an a= djacency goes down but it
=0A>shouldn't be used if the corresponding = router is unreachable.
=0A>Eventually, it will age out.
=0A>=0A>>
=0A>>  What should than Router X database conta= in ???
=0A>>
=0A>>  Router X database: Router A Cap= ability: TV1 (1,1)
=0A>>    OR
=0A>>  Ro= uter X database: Router A Capability: TV1 (0,1)
=0A>>
=0A>Ro= uter X's area A2 database will contain the latter. The capability
=0A>= ;LSA for Router A in area A1 database is no longer applicable since
=0A&= gt;Router A is unreachable.
=0A>
=0A>>
=0A>>-Vivek&= nbsp;
=0A>>
=0A>>On Sun, 19 Dec 2004 Acee Lindem wrote = :
=0A>> >Hi Vivek,
=0A>> >Independent of the capabi= lities LSA application, I don't see why a
=0A>> >router couldn'= t have different capabilities in different areas dependent
=0A>> &= gt;on configuration or policy. What do you see wrong with this?
=0A>&= gt; >
=0A>> >Speaking as work group member,
=0A>> &= gt;Acee
=0A>> >
=0A>> >Vivek Dubey wrote:
=0A>= ;> >
=0A>> >>JP,
=0A>> >>Comments inlin= ed:
=0A>> >>
=0A>> >>Indeed. In the case of T= E, there are various cases where a router may
=0A>> >>want t= o advertise a capability with different flooding scopes thus two
=0A>= > >>different opaque LSAs. For instance, a router may belong to tw= o
=0A>> >>different meshes of TE LSPs, one local to its area= (RI LSA of Type 10)
=0A>> >>one across the routing domain (= RI LSA of Type 11).
=0A>> >>
=0A>> >>vivek>= ; If i understand correctly you are referring to the case when router has a= ttached NSSA/STUB area's, otherwise RI LSA of Type 11, would suffice.
= =0A>> >>
=0A>> >>The same TLV (automesh) is used= , with different contents, carried in different LSA (type 10 and 11).
= =0A>> >>
=0A>> >>vivek> Why same TLV is requi= red to carry different contents in different scoped LSAs. What if same cont= ents are carried in both Type 10 and Type 11 RI opaque LSAs. Are we intendi= ng to hide some information across different OSPF flooding scopes ? Since r= outer's capability is independent of "Flooding Scopes", that shou= ld not be the case.
=0A>> >>
=0A>> >>Thanks=0A>> >>Vivek
=0A>> >>
=0A>> >>=
=0A>> >>
=0A>> >>
=0A>> >>On = Wed, 08 Dec 2004 JP Vasseur wrote :
=0A>> >> >Hi Vivek,=0A>> >> >
=0A>> >> >On Dec 7, 2004, at = 5:16 PM, Acee Lindem wrote:
=0A>> >> >
=0A>> >= ;> >>Hi Vivek,
=0A>> >> >>
=0A>> >= ;> >>
=0A>> >> >>Vivek Dubey wrote:
=0A>= ;> >> >>
=0A>> >> >>>Peter,
=0A&g= t;> >> >>>
=0A>> >> >>>1) In case= of ABR analogy, the information was directly relevant to
=0A>> &g= t;> >>>  OSPF routing and even than it was provided as con= figuration option,
=0A>> >> >>>  not a "s= hould" condition.
=0A>> >> >>>
=0A>> = >> >>I think the configuration option is implementation specifi= c. Although
=0A>> >> >>it is
=0A>> >> &= gt;>not covered explicitly I think RFC 3103 implies an ABR will
=0A&g= t;> >> >>redistribute
=0A>> >> >>into b= oth attached NSSAs and regular areas.
=0A>> >> >>
= =0A>> >> >>
=0A>> >> >>>
=0A&g= t;> >> >>>  Here, OSPF RI Opaque LSA is used for bot= h:
=0A>> >> >>>  a) Advertising router's OSPF = capabilities (TLV 1)
=0A>> >> >>>  b) Capablit= ies Opaque to OSPF (Any future TLVs defined)
=0A>> >> >&g= t;>
=0A>> >> >>>  And since flooding scope = is per TLV and depends on local policy,
=0A>> >> >>>= ;  there should be no dependency on Type's of area configured at OSPF<= BR>=0A>> >> >>>  level.
=0A>> >> &= gt;>>
=0A>> >> >>>2)
=0A>> >> = >>>draft>An OSPF router MAY advertise different capabilities wh= en both
=0A>> >> >>>      NSSA/stub = area type 10 LSA(s) and an AS scoped type 11 opaque
=0A>> >>= >>>      LSA is advertised.
=0A>> >>= ; >>>vivek> Capabilities here should map to different TLV's ??<= BR>=0A>> >> >>>
=0A>> >> >>>Pe= ter>I guess it can be different TLVs or different content in the
=0A&= gt;> >> >>>same TLV.
=0A>> >> >>>=
=0A>> >> >>>vivek> Different content in same TL= V, advertised in different scoped
=0A>> >> >>> = ;     LSAs (Type 10 and Type 11). Doesnt seems a good idea to me.=
=0A>> >> >>>      Any possible scen= arios?
=0A>> >> >>>
=0A>> >> >>= ;JP - can you take a shot at this? I seem to remember that you had a
=0A= >> >> >>scenario in minde.
=0A>> >> >&g= t;
=0A>> >> >
=0A>> >> >Indeed. In the = case of TE, there are various cases where a router may
=0A>> >&= gt; >want to advertise a capability with different flooding scopes thus = two
=0A>> >> >different opaque LSAs. For instance, a rout= er may belong to two
=0A>> >> >different meshes of TE LSP= s, one local to its area (RI LSA of Type 10)
=0A>> >> >on= e across the routing domain (RI LSA of Type 11). The same TLV
=0A>>= ; >> >(automesh) is used, with different contents, carried in diff= erent LSA
=0A>> >> >(type 10 and 11).
=0A>> >= > >
=0A>> >> >Thanks.
=0A>> >> ><= BR>=0A>> >> >JP.
=0A>> >> >
=0A>>= >> >>Thanks,
=0A>> >> >>Acee
=0A>&g= t; >> >>
=0A>> >> >>>
=0A>> &g= t;> >>>Thanks
=0A>> >> >>>Vivek
=0A&= gt;> >> >>>
=0A>> >> >>>
=0A&g= t;> >> >>>
=0A>> >> >>>
=0A>= ;> >> >>>
=0A>> >> >>>On Tue, 07 = Dec 2004 Peter Psenak wrote :
=0A>> >> >>> >Vive= k,
=0A>> >> >>> >
=0A>> >> >&g= t;> >Vivek Dubey wrote:
=0A>> >> >>> >>= Hi,
=0A>> >> >>> >>Section 2.3:
=0A>>= ; >> >>> >>draft>TLV flooding scope rules will be s= pecified on a per-TLV basis
=0A>> >> >>> >>dr= aft>If a type 11 opaque LSA is chosen, the originating router
=0A>= > >> >>>should
=0A>> >> >>> >&= gt;      also advertise type 10 LSA(s) into any attached NSS= A/stub area
=0A>> >> >>> >>
=0A>> &g= t;> >>> >>vivek) If scope of TLV is defined to be AS (Typ= e 11), why should,
=0A>> >> >>>the
=0A>> &= gt;> >>> >>      originating router advert= ise type 10 LSA(s) into any
=0A>> >> >>> >>&n= bsp;     attached NSSA/stub area ? Idea seems to get the capabili= ties
=0A>> >> >>> >>      adve= rtised to NSSA/STUB neighbors of originating router. But
=0A>> >= ;> >>> >>      what about NSSA/STUB areas = attached not to "originating"
=0A>> >> >>>= ; >>      routers??
=0A>> >> >>&g= t; >
=0A>> >> >>> >an analogy is when you hav= e an ABR connected to backbone area and
=0A>> >> >>>= ;NSSA
=0A>> >> >>> >area and you redistribute ro= utes from some external source. ABR will
=0A>> >> >>&g= t; >generate Type-5 external LSA, plus it can be configured to advertise=
=0A>> >> >>> >Type-7 LSA to the NSSA area for t= he same prefix.
=0A>> >> >>> >If you have anothe= r ASBR somewhere in backbone area, Type-5 LSAs it
=0A>> >> &= gt;>> >generates will not get propagated to NSSA area.
=0A>&= gt; >> >>> >
=0A>> >> >>> >>= ;
=0A>> >> >>> >>draft>An OSPF router MAY = advertise different capabilities when both
=0A>> >> >>= > >>      NSSA/stub area type 10 LSA(s) and an AS s= coped type 11 opaque
=0A>> >> >>> >>  &n= bsp;   LSA is advertised.
=0A>> >> >>> >>= ;vivek> Capabilities here should map to different TLV's ??
=0A>>= ; >> >>> >
=0A>> >> >>> >I gue= ss it can be different TLVs or different content in the same
=0A>>= >> >>>TLV.
=0A>> >> >>> >
=0A= >> >> >>> >Peter
=0A>> >> >>&g= t; >
=0A>> >> >>> >>
=0A>> >&g= t; >>> >>Thanks
=0A>> >> >>> >>= ;Vivek
=0A>> >> >>> >>
=0A>> >>= ; >>> >>
=0A>> >> >>> >>
= =0A>> >> >>> >><http://clients.rediff.com/sig= nature/track_sig.asp>
=0A>> >> >>>
=0A>>= ; >> >>>
=0A>> >> >>>
=0A>>= >> >>><http://clients.rediff.com/signature/track_sig.asp= >
=0A>> >> >>
=0A>> >>
=0A>>= ; >>
=0A>> >><http://clients.rediff.com/signature/t= rack_sig.asp>
=0A>>
=0A>>
=0A>>
=0A>>= ;<http://clients.rediff.com/signature/track_sig.asp>
=0A=0A

=0A=

=0A= =0A --Next_1105115618---0-203.199.83.246-15230-- From owner-ospf@PEACH.EASE.LSOFT.COM Fri Jan 7 15:50:15 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23690 for ; Fri, 7 Jan 2005 15:50:13 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.00F3AAC1@cherry.ease.lsoft.com>; Fri, 7 Jan 2005 15:50:10 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 52428143 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 7 Jan 2005 15:49:51 -0500 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 7 Jan 2005 15:39:51 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21412; Fri, 7 Jan 2005 15:39:47 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200501072039.PAA21412@ietf.org> Date: Fri, 7 Jan 2005 15:39:08 -0500 Reply-To: Mailing List Sender: Mailing List From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ospf-cap-05.txt Comments: To: i-d-announce@ietf.org To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF. Title : Extensions to OSPF for Advertising Optional Router Capabilities Author(s) : A. Lindem, et al. Filename : draft-ietf-ospf-cap-05.txt Pages : 14 Date : 2005-1-7 It is useful for routers in an OSPF routing domain to know the capabilities of their neighbors and other routers in the OSPF routing domain. This draft proposes extensions to OSPF for advertising optional router capabilities. A new Router Information (RI) opaque LSA is proposed for this purpose. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-cap-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ospf-cap-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ospf-cap-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-1-7152200.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ospf-cap-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ospf-cap-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-1-7152200.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@PEACH.EASE.LSOFT.COM Fri Jan 7 22:31:09 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20635 for ; Fri, 7 Jan 2005 22:31:08 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00F3B097@cherry.ease.lsoft.com>; Fri, 7 Jan 2005 22:31:04 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 52459581 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 7 Jan 2005 22:31:01 -0500 Received: from 64.102.122.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 7 Jan 2005 22:31:01 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 07 Jan 2005 22:31:01 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j083UxW0027701 for ; Fri, 7 Jan 2005 22:30:59 -0500 (EST) Received: from [10.82.240.54] (rtp-vpn2-54.cisco.com [10.82.240.54]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BEL30718; Fri, 7 Jan 2005 19:30:58 -0800 (PST) User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <41DF53F4.8050704@cisco.com> Date: Fri, 7 Jan 2005 22:31:00 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: WG Last Call for "Extensions to OSPF for Advertising Optional Router" To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit This the start of the Working Group Last Call for "Extensions to OSPF for Advertising Optional Router" - draft-ietf-ospf-cap-05.txt. All comments must be sent to the OSPF list by 12:00 AM EST on Monday, January 24, 2005. A URL for this Internet-draft is provided below: http://www.ietf.org/internet-drafts/draft-ietf-ospf-cap-05.txt Thanks, Acee From owner-ospf@PEACH.EASE.LSOFT.COM Sun Jan 9 12:04:33 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24011 for ; Sun, 9 Jan 2005 12:04:32 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.00F3E105@cherry.ease.lsoft.com>; 9 Jan 2005 12:04:30 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 52663114 for OSPF@PEACH.EASE.LSOFT.COM; Sun, 9 Jan 2005 12:04:26 -0500 Received: from 64.233.184.200 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sun, 9 Jan 2005 12:04:26 -0500 Received: by wproxy.gmail.com with SMTP id 50so283907wri for ; Sun, 09 Jan 2005 09:04:26 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=crlYWfNBJXbDHCF1Y6oBVex3oGQuhU1+YSWiPGJ9POa5gHoR15r6rkTDaosBWUC/pLC0BSM7fH/x+G/EVg8blcmttTCLFH2gv0e4CW2nZWCd4R7Mk6LqtibxPA4cT4IDrcORYtJZZkgTfy5otkTrRj4sE4VaFrJLz7oyLlxP5x0= Received: by 10.54.38.67 with SMTP id l67mr206034wrl; Sun, 09 Jan 2005 09:04:26 -0800 (PST) Received: by 10.54.13.29 with HTTP; Sun, 9 Jan 2005 09:04:26 -0800 (PST) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <000001c4f4cf$e2f60c80$0100a8c0@in.huawei.com> Message-ID: Date: Sun, 9 Jan 2005 22:34:26 +0530 Reply-To: Mailing List Sender: Mailing List From: Santosh Esale Subject: Re: Next-hop calculation To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <000001c4f4cf$e2f60c80$0100a8c0@in.huawei.com> Precedence: list Content-Transfer-Encoding: 7bit Even though RTA's interface prefix is different, it shares THE LINK with RTB and RTC, hence 3001::/64 & 4001::/64 are directly connected networks which has been advertised by DR of this network in intra-area prefix lsa, So only EXIT interface is enough to reach these networks from any of the router, hence no need of next-hop. Regards Santosh On Fri, 7 Jan 2005 21:15:16 +0530, Jayalakshmi G wrote: > Hi all, > I have a doubt in calculating next-hop for network in OSPFv3. > > Consider my topology, > > RTA > |e0 > | > RTB---------------- RTC > e1 e1 > > RTB e1's interface prefix 3001::3 / 64 > RTC e1's prefix 3001::9 / 64 > and > RTA e0's interface prefix 4000::6 / 64 > > For next hop calculation: > RFC 2740 explains the difference only in calculation for Router and rest > will be same as 2328. > RFC 2328 states: > "If the destination is a directly connected network, or a router which > connects to the calculating router via a point-to-point interface, no next > hop IP address is required." > > Above lines say, if we are calculating for a directly connected network then > we don't need any next hop. > > But, in my topology RTA's interface prefix is different from the network > 3001:: /64. > So, according to RFC 3001::/64 would seem as directly connected and would > have no next hop. Actually its next hops should be RTB's and RTC's link > local addresses. > > So, any suggestions as to how should I find the correct next-hops? > > Thanks & Regards, > Jaya > -- Regards Santosh Esale Member Technical Staff Riverstone Networks India Pvt Ltd. From owner-ospf@PEACH.EASE.LSOFT.COM Sun Jan 9 14:19:43 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00267 for ; Sun, 9 Jan 2005 14:19:43 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.00F3E1F6@cherry.ease.lsoft.com>; 9 Jan 2005 14:19:42 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 52670263 for OSPF@PEACH.EASE.LSOFT.COM; Sun, 9 Jan 2005 14:19:41 -0500 Received: from 64.102.122.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sun, 9 Jan 2005 14:19:18 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 09 Jan 2005 14:31:41 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j09JJFW0026267 for ; Sun, 9 Jan 2005 14:19:16 -0500 (EST) Received: from [10.82.240.54] (rtp-vpn2-54.cisco.com [10.82.240.54]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BEL60066; Sun, 9 Jan 2005 11:19:14 -0800 (PST) User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <8D260779A766FB4A9C1739A476F84FA401F79BAC@daebe009.americas.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <41E183B1.1000900@cisco.com> Date: Sun, 9 Jan 2005 14:19:13 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: draft-ietf-ospf-ospfv3-auth-06.txt Ready for IESG review To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <8D260779A766FB4A9C1739A476F84FA401F79BAC@daebe009.americas.nokia.com> Precedence: list Content-Transfer-Encoding: 7bit Mukesh, Vishwas, Here is my take. The document should be written in such a way that it doesn't need to be updated every time the IPSec algorithm de jour changes. However, I also think the document should specify algorithms with the caveat that they may be updated. IMHO, once an authentication/encrpytion algorithm is deployed, it is unlikely to be withdrawn from support. Hence, if someone develops a stronger algorithm with lower computational requirements and it becomes the recommended alogorithm, then implementations will need to support it in ADDITION to what they are currently supporting. Is this possible? Any other opinions? Thanks, Acee Mukesh Gupta wrote: >Vishwas, > >Comments inline.. > > > >>VM> I do not think you talk about encryption at all when you >>talk about >>AH. If you check the documents I have pointed to carefully, >>you will see >>NULL Encryption is a special case of encryption when encryption is not >>used. >> >> > >Would it make more sense if we change the text "NULL encryption" >to "NULL encryption (for ESP) or no encryption (for AH)" ? > > > >>Suresh> We are not a fan of DES either for obvious reasons. But as we >>wanted to start with the weakest algorithm, we started with DES. We >>wouldn't have to mention DES at all, had IETF/NIST >>suggested DES as "MUST NOT". >>VM> I still don't see a reason why we should talk about DES at all. >> >> > >I still don't understand why we can't use DES as an example of a weak >encryption algorithm. > >I would like to hear others' opnion about this ? Acee? > > > >>Suresh> Mukesh and I discussed this again and we agree that >>referring to >>the IPsec algorithm draft should be the better way to go. >>VM> Also not for the authentication you have given the key length and >>for Encryption you have not(so there is anyway a case of >>inconsistency). >> >> > >Yeah but this will be fixed too if we didn't mention any algorithm >and just pointed to the madatory to implement algos. Right ? > > > >>Suresh> What about the following: >>"Replaying these type of packets can make the router spend some >>resources. Also when the OSPF adjacency is not FULL, replaying >>database description packets can cause disruption in forming the >>adjacency." >>VM> Its not just forming the adjacency Suresh but the link becoming >>unusable for transit traffic (DoS). In my view you should >>just refer to >>the vulnerabilities draft and probably put a sentence like the above. >> >> > >We do refer to the vulnerabilities draft after the brief discussion >of the replay vulnerabilities.. So are you ok with putting the >text proposed above and then referring to the vulerabilities draft ? > > > >>VM> You are right. However I think the aim of the draft is to specify >>how we should use IPSec (guidelines) as well as specify the default >>behavior(Maybe for all optional parameters we should specify this). >> >> > >You are right. The aim of this draft is to specify how OSPFv3 should >use IPsec but I still fail to understand why we need to specify things >that are not related or exposed to OSPF :( > >What exactly do you want to specify about ESN? Do we want to say >that there is no impact of the usage of ESN by the underlying IPsec >implementation on OSPFv3 security because sequence numbers are ignored >while manual keys are used ? > >Regards >Mukesh > > > From owner-ospf@PEACH.EASE.LSOFT.COM Sun Jan 9 23:08:53 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00802 for ; Sun, 9 Jan 2005 23:08:53 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00F3E8D3@cherry.ease.lsoft.com>; 9 Jan 2005 23:08:53 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 52698062 for OSPF@PEACH.EASE.LSOFT.COM; Sun, 9 Jan 2005 23:08:52 -0500 Received: from 63.197.255.158 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sun, 9 Jan 2005 23:08:52 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: draft-ietf-ospf-ospfv3-auth-06.txt Ready for IESG review thread-index: AcT2gXRAoVKYcDZUSEKeUxrHKSX+CQASPhlA Message-ID: Date: Sun, 9 Jan 2005 20:16:45 -0800 Reply-To: Mailing List Sender: Mailing List From: Vishwas Manral Subject: Re: draft-ietf-ospf-ospfv3-auth-06.txt Ready for IESG review To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Hi Acee, I agree totally with your views.=20 However examples where algorithms "support has been changed" are: -=20 " Old Old New Req. RFC(s) Requirement Algorithm (notes) --- ------ ----------- --------- MUST 2406 SHOULD NOT DES-CBC [RFC 2405] (1) MUST 2402 2406 MAY HMAC-MD5-96 [RFC 2403] MUST 2402 2406 MUST HMAC-SHA1-96 [RFC 2404] " Thanks, Vishwas -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Acee Lindem Sent: Monday, January 10, 2005 12:49 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: draft-ietf-ospf-ospfv3-auth-06.txt Ready for IESG review Mukesh, Vishwas, Here is my take. The document should be written in such a way that it doesn't need to be updated every time the IPSec algorithm de jour changes. However, I also think the document should specify algorithms with the caveat that they may be updated. IMHO, once an authentication/encrpytion algorithm is deployed, it is unlikely to be withdrawn from support. Hence, if someone develops a stronger algorithm with lower computational=20 requirements and it becomes the recommended alogorithm, then implementations will need to support it in ADDITION to what they are currently supporting. Is this possible? Any other opinions? Thanks, Acee Mukesh Gupta wrote: >Vishwas, > >Comments inline.. > > =20 > >>VM> I do not think you talk about encryption at all when you=20 >>talk about >>AH. If you check the documents I have pointed to carefully,=20 >>you will see >>NULL Encryption is a special case of encryption when encryption is not >>used. >> =20 >> > >Would it make more sense if we change the text "NULL encryption"=20 >to "NULL encryption (for ESP) or no encryption (for AH)" ? > > =20 > >>Suresh> We are not a fan of DES either for obvious reasons. But as we >>wanted to start with the weakest algorithm, we started with DES. We >>wouldn't have to mention DES at all, had IETF/NIST=20 >>suggested DES as "MUST NOT". >>VM> I still don't see a reason why we should talk about DES at all. >> =20 >> > >I still don't understand why we can't use DES as an example of a weak >encryption algorithm. =20 > >I would like to hear others' opnion about this ? Acee? > > =20 > >>Suresh> Mukesh and I discussed this again and we agree that=20 >>referring to >>the IPsec algorithm draft should be the better way to go. =20 >>VM> Also not for the authentication you have given the key length and >>for Encryption you have not(so there is anyway a case of=20 >>inconsistency). >> =20 >> > >Yeah but this will be fixed too if we didn't mention any algorithm >and just pointed to the madatory to implement algos. Right ? > > =20 > >>Suresh> What about the following: >>"Replaying these type of packets can make the router spend some >>resources. Also when the OSPF adjacency is not FULL, replaying=20 >>database description packets can cause disruption in forming the >>adjacency." >>VM> Its not just forming the adjacency Suresh but the link becoming >>unusable for transit traffic (DoS). In my view you should=20 >>just refer to >>the vulnerabilities draft and probably put a sentence like the above. >> =20 >> > >We do refer to the vulnerabilities draft after the brief discussion >of the replay vulnerabilities.. So are you ok with putting the >text proposed above and then referring to the vulerabilities draft ? > > =20 > >>VM> You are right. However I think the aim of the draft is to specify >>how we should use IPSec (guidelines) as well as specify the default >>behavior(Maybe for all optional parameters we should specify this). >> =20 >> > >You are right. The aim of this draft is to specify how OSPFv3 should >use IPsec but I still fail to understand why we need to specify things >that are not related or exposed to OSPF :( > >What exactly do you want to specify about ESN? Do we want to say >that there is no impact of the usage of ESN by the underlying IPsec >implementation on OSPFv3 security because sequence numbers are ignored >while manual keys are used ? > >Regards >Mukesh > > =20 > From owner-ospf@PEACH.EASE.LSOFT.COM Mon Jan 10 00:49:54 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05655 for ; Mon, 10 Jan 2005 00:49:52 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.00F3EC27@cherry.ease.lsoft.com>; Mon, 10 Jan 2005 0:49:51 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 52705185 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 10 Jan 2005 00:49:42 -0500 Received: from 131.228.20.26 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 10 Jan 2005 00:49:42 -0500 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0A5nYi04316 for ; Mon, 10 Jan 2005 07:49:41 +0200 (EET) X-Scanned: Mon, 10 Jan 2005 07:48:00 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id j0A5m0gQ002172 for ; Mon, 10 Jan 2005 07:48:00 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 006se87g; Mon, 10 Jan 2005 07:47:58 EET Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0A5lcU28234 for ; Mon, 10 Jan 2005 07:47:38 +0200 (EET) Received: from daebe009.NOE.Nokia.com ([10.241.35.109]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Sun, 9 Jan 2005 23:47:29 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: draft-ietf-ospf-ospfv3-auth-06.txt Ready for IESG review thread-index: AcT0YyKUKN+2jhfMQtG30BwiBt67fgADHBMgAAaItqAAArMHMACQcyBg X-OriginalArrivalTime: 10 Jan 2005 05:47:29.0134 (UTC) FILETIME=[DEE7A0E0:01C4F6D7] Message-ID: <8D260779A766FB4A9C1739A476F84FA401F79BB1@daebe009.americas.nokia.com> Date: Sun, 9 Jan 2005 23:47:28 -0600 Reply-To: Mailing List Sender: Mailing List From: Mukesh Gupta Subject: Re: draft-ietf-ospf-ospfv3-auth-06.txt Ready for IESG review To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Vishwas, Comments inline :) > Would it make more sense if we change the text "NULL encryption"=20 > to "NULL encryption (for ESP) or no encryption (for AH)" ? > VM> OK. Ok. We have consensus on one thing :) We will take care of this in the next rev. > > VM> I still don't see a reason why we should talk about DES at all. > I still don't understand why we can't use DES as an example of a weak > encryption algorithm. =20 > I would like to hear others' opnion about this ? Acee? > VM> I think examples should not be given of protocols which are on the > "SHOULD NOT" list of IETF/NIST. I still don't quite agree with you here. Lets hear from others on this ! Acee, what is your opinion on this ? > VM> Yes, however I think we should be specifying a default=20 > algorithm for > OSPF(or are you saying you are not specifying any algorithms instead > just directly pointing to the ESP/AH algorithms document). I will cover this in the separate mail. I am frankly quite confused about what we want here :) > We do refer to the vulnerabilities draft after the brief discussion > of the replay vulnerabilities.. So are you ok with putting the > text proposed above and then referring to the vulerabilities draft ? > VM> As long as you put the text for the DoS case too, I am=20 > ok. Else let us directly point to the vulnerabilities draft without=20 > mentioning cases. Another try on the text :) How about the following + the already existing text that refers to the vulnerability draft ? =3D=3D=3D "Replaying these type of packets can make the router spend some resources. Also when the OSPF adjacency is not FULL, replaying=20 database description packets can cause disruption in forming the adjacency which can lead to DoS attack on the network." =3D=3D=3D > VM> As Suresh rightly said ESN does not make sense with manual keying. > So it is not about ESN alone. DSCP was one example I had pointed out > too. Would you be kind enough to propose some specific text and the place in the draft where it should be added ? > Thanks and sorry for bothering you, You are not bothering us ! Thanks to you for reviewing the draft=20 so many times and spending so much time on the issues. We appreciate=20 it ! Regards Mukesh From owner-ospf@PEACH.EASE.LSOFT.COM Mon Jan 10 01:54:45 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09185 for ; Mon, 10 Jan 2005 01:54:45 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.00F3ED0A@cherry.ease.lsoft.com>; Mon, 10 Jan 2005 1:54:44 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 52708027 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 10 Jan 2005 01:54:39 -0500 Received: from 131.228.20.22 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 10 Jan 2005 01:54:38 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0A6sfs06728 for ; Mon, 10 Jan 2005 08:54:41 +0200 (EET) X-Scanned: Mon, 10 Jan 2005 09:00:29 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id j0A70TwX022128 for ; Mon, 10 Jan 2005 09:00:29 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 005741r0; Mon, 10 Jan 2005 09:00:27 EET Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0A6dRU21652 for ; Mon, 10 Jan 2005 08:39:27 +0200 (EET) Received: from daebe009.NOE.Nokia.com ([10.241.35.109]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 10 Jan 2005 00:39:27 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: draft-ietf-ospf-ospfv3-auth-06.txt Ready for IESG review thread-index: AcT2gXRAoVKYcDZUSEKeUxrHKSX+CQASPhlAAANkP2A= X-OriginalArrivalTime: 10 Jan 2005 06:39:27.0057 (UTC) FILETIME=[2154EC10:01C4F6DF] Message-ID: <8D260779A766FB4A9C1739A476F84FA401F79BB2@daebe009.americas.nokia.com> Date: Mon, 10 Jan 2005 00:39:26 -0600 Reply-To: Mailing List Sender: Mailing List From: Mukesh Gupta Subject: Re: draft-ietf-ospf-ospfv3-auth-06.txt Ready for IESG review To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Acee, Vishwas is right. I don't think we can mandate a specific algorithm in the draft and not have to update it in future. What about we say something like.. =3D=3D=3D=3D This specification does not mandate specific encryption and=20 authentication algorithms because the recommendation for encryption and authentication algorithms changes with time as the algorithms are broken and more secure algorithms are invented. In order to interoperate with each other, the implementations have to have at least one common algorithm that the user can choose to use for OSPFv3 security. The implementation MUST allow the user to choose all the encryption and authentication algorithm that are MUST in IPsec mandatory to=20 implement algorithms. The implementation SHOULD allow the user to choose all the encryption and authentication algorithm that are SHOULD in IPsec mandatory to=20 implement algorithms. =3D=3D=3D=3D Regards Mukesh > -----Original Message----- > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of ext > Vishwas Manral > Sent: Sunday, January 09, 2005 8:17 PM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Re: draft-ietf-ospf-ospfv3-auth-06.txt Ready for IESG review >=20 >=20 > Hi Acee, >=20 > I agree totally with your views.=20 >=20 > However examples where algorithms "support has been changed" are: -=20 >=20 > " > Old Old New > Req. RFC(s) Requirement Algorithm (notes) > --- ------ ----------- --------- > MUST 2406 SHOULD NOT DES-CBC [RFC 2405] (1) > MUST 2402 2406 MAY HMAC-MD5-96 [RFC 2403] > MUST 2402 2406 MUST HMAC-SHA1-96 [RFC 2404] > " >=20 > Thanks, > Vishwas >=20 > -----Original Message----- > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On=20 > Behalf Of Acee > Lindem > Sent: Monday, January 10, 2005 12:49 AM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Re: draft-ietf-ospf-ospfv3-auth-06.txt Ready for IESG review >=20 > Mukesh, Vishwas, >=20 > Here is my take. The document should be written in such > a way that it doesn't need to be updated every time the=20 > IPSec algorithm > de jour changes. >=20 > However, I also think the document should specify algorithms with the > caveat that they may be updated. IMHO, once an=20 > authentication/encrpytion > algorithm is deployed, it is unlikely to be withdrawn from support. > Hence, > if someone develops a stronger algorithm with lower computational=20 > requirements > and it becomes the recommended alogorithm, then implementations will > need > to support it in ADDITION to what they are currently supporting. >=20 > Is this possible? Any other opinions? >=20 > Thanks, > Acee >=20 >=20 > Mukesh Gupta wrote: >=20 > >Vishwas, > > > >Comments inline.. > > > > =20 > > > >>VM> I do not think you talk about encryption at all when you=20 > >>talk about > >>AH. If you check the documents I have pointed to carefully,=20 > >>you will see > >>NULL Encryption is a special case of encryption when=20 > encryption is not > >>used. > >> =20 > >> > > > >Would it make more sense if we change the text "NULL encryption"=20 > >to "NULL encryption (for ESP) or no encryption (for AH)" ? > > > > =20 > > > >>Suresh> We are not a fan of DES either for obvious reasons.=20 > But as we > >>wanted to start with the weakest algorithm, we started with DES. We > >>wouldn't have to mention DES at all, had IETF/NIST=20 > >>suggested DES as "MUST NOT". > >>VM> I still don't see a reason why we should talk about DES at all. > >> =20 > >> > > > >I still don't understand why we can't use DES as an example of a weak > >encryption algorithm. =20 > > > >I would like to hear others' opnion about this ? Acee? > > > > =20 > > > >>Suresh> Mukesh and I discussed this again and we agree that=20 > >>referring to > >>the IPsec algorithm draft should be the better way to go. =20 > >>VM> Also not for the authentication you have given the key=20 > length and > >>for Encryption you have not(so there is anyway a case of=20 > >>inconsistency). > >> =20 > >> > > > >Yeah but this will be fixed too if we didn't mention any algorithm > >and just pointed to the madatory to implement algos. Right ? > > > > =20 > > > >>Suresh> What about the following: > >>"Replaying these type of packets can make the router spend some > >>resources. Also when the OSPF adjacency is not FULL, replaying=20 > >>database description packets can cause disruption in forming the > >>adjacency." > >>VM> Its not just forming the adjacency Suresh but the link becoming > >>unusable for transit traffic (DoS). In my view you should=20 > >>just refer to > >>the vulnerabilities draft and probably put a sentence like=20 > the above. > >> =20 > >> > > > >We do refer to the vulnerabilities draft after the brief discussion > >of the replay vulnerabilities.. So are you ok with putting the > >text proposed above and then referring to the vulerabilities draft ? > > > > =20 > > > >>VM> You are right. However I think the aim of the draft is=20 > to specify > >>how we should use IPSec (guidelines) as well as specify the default > >>behavior(Maybe for all optional parameters we should specify this). > >> =20 > >> > > > >You are right. The aim of this draft is to specify how OSPFv3 should > >use IPsec but I still fail to understand why we need to=20 > specify things > >that are not related or exposed to OSPF :( > > > >What exactly do you want to specify about ESN? Do we want to say > >that there is no impact of the usage of ESN by the underlying IPsec > >implementation on OSPFv3 security because sequence numbers=20 > are ignored > >while manual keys are used ? > > > >Regards > >Mukesh > > > > =20 > > >=20 From owner-ospf@PEACH.EASE.LSOFT.COM Mon Jan 10 01:59:04 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09331 for ; Mon, 10 Jan 2005 01:59:03 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00F3ECCB@cherry.ease.lsoft.com>; Mon, 10 Jan 2005 1:59:03 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 52708218 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 10 Jan 2005 01:58:58 -0500 Received: from 63.197.255.158 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 10 Jan 2005 01:58:57 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: draft-ietf-ospf-ospfv3-auth-06.txt Ready for IESG review thread-index: AcT2gXRAoVKYcDZUSEKeUxrHKSX+CQASPhlAAANkP2AAArAWEA== Message-ID: Date: Sun, 9 Jan 2005 23:07:00 -0800 Reply-To: Mailing List Sender: Mailing List From: Vishwas Manral Subject: Re: draft-ietf-ospf-ospfv3-auth-06.txt Ready for IESG review To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Hi Mukesh, I am ok with the text. Thanks, Vishwas -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Mukesh Gupta Sent: Monday, January 10, 2005 12:09 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: draft-ietf-ospf-ospfv3-auth-06.txt Ready for IESG review Acee, Vishwas is right. I don't think we can mandate a specific algorithm in the draft and not have to update it in future. What about we say something like.. =3D=3D=3D=3D This specification does not mandate specific encryption and=20 authentication algorithms because the recommendation for encryption and authentication algorithms changes with time as the algorithms are broken and more secure algorithms are invented. In order to interoperate with each other, the implementations have to have at least one common algorithm that the user can choose to use for OSPFv3 security. The implementation MUST allow the user to choose all the encryption and authentication algorithm that are MUST in IPsec mandatory to=20 implement algorithms. The implementation SHOULD allow the user to choose all the encryption and authentication algorithm that are SHOULD in IPsec mandatory to=20 implement algorithms. =3D=3D=3D=3D Regards Mukesh > -----Original Message----- > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of ext > Vishwas Manral > Sent: Sunday, January 09, 2005 8:17 PM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Re: draft-ietf-ospf-ospfv3-auth-06.txt Ready for IESG review >=20 >=20 > Hi Acee, >=20 > I agree totally with your views.=20 >=20 > However examples where algorithms "support has been changed" are: -=20 >=20 > " > Old Old New > Req. RFC(s) Requirement Algorithm (notes) > --- ------ ----------- --------- > MUST 2406 SHOULD NOT DES-CBC [RFC 2405] (1) > MUST 2402 2406 MAY HMAC-MD5-96 [RFC 2403] > MUST 2402 2406 MUST HMAC-SHA1-96 [RFC 2404] > " >=20 > Thanks, > Vishwas >=20 > -----Original Message----- > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On=20 > Behalf Of Acee > Lindem > Sent: Monday, January 10, 2005 12:49 AM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Re: draft-ietf-ospf-ospfv3-auth-06.txt Ready for IESG review >=20 > Mukesh, Vishwas, >=20 > Here is my take. The document should be written in such > a way that it doesn't need to be updated every time the=20 > IPSec algorithm > de jour changes. >=20 > However, I also think the document should specify algorithms with the > caveat that they may be updated. IMHO, once an=20 > authentication/encrpytion > algorithm is deployed, it is unlikely to be withdrawn from support. > Hence, > if someone develops a stronger algorithm with lower computational=20 > requirements > and it becomes the recommended alogorithm, then implementations will > need > to support it in ADDITION to what they are currently supporting. >=20 > Is this possible? Any other opinions? >=20 > Thanks, > Acee >=20 >=20 > Mukesh Gupta wrote: >=20 > >Vishwas, > > > >Comments inline.. > > > > =20 > > > >>VM> I do not think you talk about encryption at all when you=20 > >>talk about > >>AH. If you check the documents I have pointed to carefully,=20 > >>you will see > >>NULL Encryption is a special case of encryption when=20 > encryption is not > >>used. > >> =20 > >> > > > >Would it make more sense if we change the text "NULL encryption"=20 > >to "NULL encryption (for ESP) or no encryption (for AH)" ? > > > > =20 > > > >>Suresh> We are not a fan of DES either for obvious reasons.=20 > But as we > >>wanted to start with the weakest algorithm, we started with DES. We > >>wouldn't have to mention DES at all, had IETF/NIST=20 > >>suggested DES as "MUST NOT". > >>VM> I still don't see a reason why we should talk about DES at all. > >> =20 > >> > > > >I still don't understand why we can't use DES as an example of a weak > >encryption algorithm. =20 > > > >I would like to hear others' opnion about this ? Acee? > > > > =20 > > > >>Suresh> Mukesh and I discussed this again and we agree that=20 > >>referring to > >>the IPsec algorithm draft should be the better way to go. =20 > >>VM> Also not for the authentication you have given the key=20 > length and > >>for Encryption you have not(so there is anyway a case of=20 > >>inconsistency). > >> =20 > >> > > > >Yeah but this will be fixed too if we didn't mention any algorithm > >and just pointed to the madatory to implement algos. Right ? > > > > =20 > > > >>Suresh> What about the following: > >>"Replaying these type of packets can make the router spend some > >>resources. Also when the OSPF adjacency is not FULL, replaying=20 > >>database description packets can cause disruption in forming the > >>adjacency." > >>VM> Its not just forming the adjacency Suresh but the link becoming > >>unusable for transit traffic (DoS). In my view you should=20 > >>just refer to > >>the vulnerabilities draft and probably put a sentence like=20 > the above. > >> =20 > >> > > > >We do refer to the vulnerabilities draft after the brief discussion > >of the replay vulnerabilities.. So are you ok with putting the > >text proposed above and then referring to the vulerabilities draft ? > > > > =20 > > > >>VM> You are right. However I think the aim of the draft is=20 > to specify > >>how we should use IPSec (guidelines) as well as specify the default > >>behavior(Maybe for all optional parameters we should specify this). > >> =20 > >> > > > >You are right. The aim of this draft is to specify how OSPFv3 should > >use IPsec but I still fail to understand why we need to=20 > specify things > >that are not related or exposed to OSPF :( > > > >What exactly do you want to specify about ESN? Do we want to say > >that there is no impact of the usage of ESN by the underlying IPsec > >implementation on OSPFv3 security because sequence numbers=20 > are ignored > >while manual keys are used ? > > > >Regards > >Mukesh > > > > =20 > > >=20 From owner-ospf@PEACH.EASE.LSOFT.COM Mon Jan 10 05:11:42 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05497 for ; Mon, 10 Jan 2005 05:11:40 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.00F3EF68@cherry.ease.lsoft.com>; Mon, 10 Jan 2005 5:11:38 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 52718120 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 10 Jan 2005 05:11:36 -0500 Received: from 61.144.161.53 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 10 Jan 2005 05:11:35 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IA300MB2IY81R@szxga01-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Mon, 10 Jan 2005 18:10:57 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IA300D3NIY88S@szxga01-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Mon, 10 Jan 2005 18:10:56 +0800 (CST) Received: from Jayalakshmig ([10.18.4.193]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IA30049EJ3D0F@szxml01-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Mon, 10 Jan 2005 18:14:03 +0800 (CST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Message-ID: <000001c4f6fd$8ecced10$0100a8c0@in.huawei.com> Date: Mon, 10 Jan 2005 15:47:14 +0530 Reply-To: Mailing List Sender: Mailing List From: Jayalakshmi G Organization: HUAWEI Subject: Re: Next-hop calculation To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7BIT Hi Santosh, Setting the exit interface is not enough to reach the network in case of IPv6. Because in IPv6, the destination prefix and the source-interface address should have a common subnet-prefix. Else ping will fail. So, for network-routes we should set an explicit next hop. But as I said before, RFC 2740 doesn't consider this issue. We need to have a way to find the correct next-hop. Regards, Jaya -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Santosh Esale Sent: Sunday, January 09, 2005 10:34 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: Next-hop calculation Even though RTA's interface prefix is different, it shares THE LINK with RTB and RTC, hence 3001::/64 & 4001::/64 are directly connected networks which has been advertised by DR of this network in intra-area prefix lsa, So only EXIT interface is enough to reach these networks from any of the router, hence no need of next-hop. Regards Santosh On Fri, 7 Jan 2005 21:15:16 +0530, Jayalakshmi G wrote: > Hi all, > I have a doubt in calculating next-hop for network in OSPFv3. > > Consider my topology, > > RTA > |e0 > | > RTB---------------- RTC > e1 e1 > > RTB e1's interface prefix 3001::3 / 64 > RTC e1's prefix 3001::9 / 64 > and > RTA e0's interface prefix 4000::6 / 64 > > For next hop calculation: > RFC 2740 explains the difference only in calculation for Router and rest > will be same as 2328. > RFC 2328 states: > "If the destination is a directly connected network, or a router which > connects to the calculating router via a point-to-point interface, no next > hop IP address is required." > > Above lines say, if we are calculating for a directly connected network then > we don't need any next hop. > > But, in my topology RTA's interface prefix is different from the network > 3001:: /64. > So, according to RFC 3001::/64 would seem as directly connected and would > have no next hop. Actually its next hops should be RTB's and RTC's link > local addresses. > > So, any suggestions as to how should I find the correct next-hops? > > Thanks & Regards, > Jaya > -- Regards Santosh Esale Member Technical Staff Riverstone Networks India Pvt Ltd. From owner-ospf@PEACH.EASE.LSOFT.COM Mon Jan 10 07:32:53 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14258 for ; Mon, 10 Jan 2005 07:32:51 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00F3F145@cherry.ease.lsoft.com>; Mon, 10 Jan 2005 7:32:46 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 52769488 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 10 Jan 2005 07:32:45 -0500 Received: from 207.217.121.251 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 10 Jan 2005 07:32:44 -0500 Received: from user-38ldsnp.dialup.mindspring.com ([209.86.242.249] helo=earthlink.net) by pop-a065d10.pas.sa.earthlink.net with esmtp (Exim 3.33 #1) id 1Cnyiv-0004TI-00 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 10 Jan 2005 04:32:42 -0800 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <41E2768A.A2C70EAE@earthlink.net> Date: Mon, 10 Jan 2005 04:35:22 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: draft-ietf-ospf-ospfv3-auth-06.txt Ready for IESG review To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Wow, > This specification does not mandate specific encryption and > authentication algorithms because the recommendation for encryption > and authentication algorithms changes with time as the algorithms > are broken and more secure algorithms are invented. > Sorry, I am lost with this. The devil in me says that this means to DELAY" this RFC until a SECURE algorithm that will NEVER need to be changed is identified. OSPF has specified features and is documented and is changed in the future with later RFCs. What is wrong with guaranteeing that at least one algoritm is specified for interoperability? Then as better algorithms are identified, then they are specified in later docs and superseed earlier algorithms. Then only the first algorithm is a MUST support and later algorithms need be a SHOULD supported for later compatibility. Right.. Yes, the full set could be supported, but is probably not a must, since the first is guaranteed... Thus, isn't at least one specified so so algorithm better than guaranteeing NULL for encryption, etc? Mitchell Erblich ---------------- Vishwas Manral wrote: > > Hi Mukesh, > > I am ok with the text. > > Thanks, > Vishwas > -----Original Message----- > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of > Mukesh Gupta > Sent: Monday, January 10, 2005 12:09 PM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Re: draft-ietf-ospf-ospfv3-auth-06.txt Ready for IESG review > > Acee, > > Vishwas is right. I don't think we can mandate a specific algorithm > in the draft and not have to update it in future. > > What about we say something like.. > > ==== > This specification does not mandate specific encryption and > authentication algorithms because the recommendation for encryption > and authentication algorithms changes with time as the algorithms > are broken and more secure algorithms are invented. > > In order to interoperate with each other, the implementations have > to have at least one common algorithm that the user can choose to > use for OSPFv3 security. > > The implementation MUST allow the user to choose all the encryption > and authentication algorithm that are MUST in IPsec mandatory to > implement algorithms. > > The implementation SHOULD allow the user to choose all the encryption > and authentication algorithm that are SHOULD in IPsec mandatory to > implement algorithms. > ==== > > Regards > Mukesh > > > -----Original Message----- > > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of ext > > Vishwas Manral > > Sent: Sunday, January 09, 2005 8:17 PM > > To: OSPF@PEACH.EASE.LSOFT.COM > > Subject: Re: draft-ietf-ospf-ospfv3-auth-06.txt Ready for IESG review > > > > > > Hi Acee, > > > > I agree totally with your views. > > > > However examples where algorithms "support has been changed" are: - > > > > " > > Old Old New > > Req. RFC(s) Requirement Algorithm (notes) > > --- ------ ----------- --------- > > MUST 2406 SHOULD NOT DES-CBC [RFC 2405] (1) > > MUST 2402 2406 MAY HMAC-MD5-96 [RFC 2403] > > MUST 2402 2406 MUST HMAC-SHA1-96 [RFC 2404] > > " > > > > Thanks, > > Vishwas > > > > -----Original Message----- > > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On > > Behalf Of Acee > > Lindem > > Sent: Monday, January 10, 2005 12:49 AM > > To: OSPF@PEACH.EASE.LSOFT.COM > > Subject: Re: draft-ietf-ospf-ospfv3-auth-06.txt Ready for IESG review > > > > Mukesh, Vishwas, > > > > Here is my take. The document should be written in such > > a way that it doesn't need to be updated every time the > > IPSec algorithm > > de jour changes. > > > > However, I also think the document should specify algorithms with the > > caveat that they may be updated. IMHO, once an > > authentication/encrpytion > > algorithm is deployed, it is unlikely to be withdrawn from support. > > Hence, > > if someone develops a stronger algorithm with lower computational > > requirements > > and it becomes the recommended alogorithm, then implementations will > > need > > to support it in ADDITION to what they are currently supporting. > > > > Is this possible? Any other opinions? > > > > Thanks, > > Acee > > > > > > Mukesh Gupta wrote: > > > > >Vishwas, > > > > > >Comments inline.. > > > > > > > > > > > >>VM> I do not think you talk about encryption at all when you > > >>talk about > > >>AH. If you check the documents I have pointed to carefully, > > >>you will see > > >>NULL Encryption is a special case of encryption when > > encryption is not > > >>used. > > >> > > >> > > > > > >Would it make more sense if we change the text "NULL encryption" > > >to "NULL encryption (for ESP) or no encryption (for AH)" ? > > > > > > > > > > > >>Suresh> We are not a fan of DES either for obvious reasons. > > But as we > > >>wanted to start with the weakest algorithm, we started with DES. We > > >>wouldn't have to mention DES at all, had IETF/NIST > > >>suggested DES as "MUST NOT". > > >>VM> I still don't see a reason why we should talk about DES at all. > > >> > > >> > > > > > >I still don't understand why we can't use DES as an example of a weak > > >encryption algorithm. > > > > > >I would like to hear others' opnion about this ? Acee? > > > > > > > > > > > >>Suresh> Mukesh and I discussed this again and we agree that > > >>referring to > > >>the IPsec algorithm draft should be the better way to go. > > >>VM> Also not for the authentication you have given the key > > length and > > >>for Encryption you have not(so there is anyway a case of > > >>inconsistency). > > >> > > >> > > > > > >Yeah but this will be fixed too if we didn't mention any algorithm > > >and just pointed to the madatory to implement algos. Right ? > > > > > > > > > > > >>Suresh> What about the following: > > >>"Replaying these type of packets can make the router spend some > > >>resources. Also when the OSPF adjacency is not FULL, replaying > > >>database description packets can cause disruption in forming the > > >>adjacency." > > >>VM> Its not just forming the adjacency Suresh but the link becoming > > >>unusable for transit traffic (DoS). In my view you should > > >>just refer to > > >>the vulnerabilities draft and probably put a sentence like > > the above. > > >> > > >> > > > > > >We do refer to the vulnerabilities draft after the brief discussion > > >of the replay vulnerabilities.. So are you ok with putting the > > >text proposed above and then referring to the vulerabilities draft ? > > > > > > > > > > > >>VM> You are right. However I think the aim of the draft is > > to specify > > >>how we should use IPSec (guidelines) as well as specify the default > > >>behavior(Maybe for all optional parameters we should specify this). > > >> > > >> > > > > > >You are right. The aim of this draft is to specify how OSPFv3 should > > >use IPsec but I still fail to understand why we need to > > specify things > > >that are not related or exposed to OSPF :( > > > > > >What exactly do you want to specify about ESN? Do we want to say > > >that there is no impact of the usage of ESN by the underlying IPsec > > >implementation on OSPFv3 security because sequence numbers > > are ignored > > >while manual keys are used ? > > > > > >Regards > > >Mukesh > > > > > > > > > > > From owner-ospf@PEACH.EASE.LSOFT.COM Mon Jan 10 10:17:37 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24966 for ; Mon, 10 Jan 2005 10:17:36 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.00F3F52D@cherry.ease.lsoft.com>; Mon, 10 Jan 2005 10:17:35 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 52788071 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 10 Jan 2005 10:17:34 -0500 Received: from 64.233.184.207 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 10 Jan 2005 10:17:33 -0500 Received: by wproxy.gmail.com with SMTP id 71so45696wri for ; Mon, 10 Jan 2005 07:17:33 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=hDc+x9TJYz0mcdew867ovq7OcpeWEGzYU9IABXU+vDLQRj+hNAXrM2YLIKwauNYn7rRYkDi5NS+Hxk7M65ffm4l+6FItSGEsg2eodJZfSfy2hcNsN51xSaPfhFDZ3M/ai52q2J80cZEhbXr/YjxuTIsz0Ocjg1jcIg+NFh331Lc= Received: by 10.54.38.43 with SMTP id l43mr78117wrl; Mon, 10 Jan 2005 07:17:33 -0800 (PST) Received: by 10.54.13.29 with HTTP; Mon, 10 Jan 2005 07:17:33 -0800 (PST) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <000001c4f6fd$8ecced10$0100a8c0@in.huawei.com> Message-ID: Date: Mon, 10 Jan 2005 20:47:33 +0530 Reply-To: Mailing List Sender: Mailing List From: Santosh Esale Subject: Re: Next-hop calculation To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <000001c4f6fd$8ecced10$0100a8c0@in.huawei.com> Precedence: list Content-Transfer-Encoding: 7bit Hi jaya, OSPFv3 RFC assumes that two routers can talk directly over a single link even if they won't share a COMMON IP subnet(Hence no need to set next-hop for network routes),which is contradictory to your below mail. IPV6 RFCs need to be checked throughly to find out why ping is failing. RFC 2740 section 2.1 --------------------------------- 2.1. Protocol processing per-link, not per-subnet IPv6 uses the term "link" to indicate "a communication facility or medium over which nodes can communicate at the link layer" ([Ref14]). "Interfaces" connect to links. Multiple IP subnets can be assigned to a single link, and two nodes can talk directly over a single link, even if they do not share a common IP subnet (IPv6 prefix). regards Santosh On Mon, 10 Jan 2005 15:47:14 +0530, Jayalakshmi G wrote: > Hi Santosh, > Setting the exit interface is not enough to reach the network in case of > IPv6. Because in IPv6, the destination prefix and the source-interface > address should have a common subnet-prefix. Else ping will fail. > > So, for network-routes we should set an explicit next hop. But as I said > before, RFC 2740 doesn't consider this issue. We need to have a way to find > the correct next-hop. > > Regards, > Jaya > > -----Original Message----- > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Santosh > Esale > Sent: Sunday, January 09, 2005 10:34 PM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Re: Next-hop calculation > > Even though RTA's interface prefix is different, it shares THE LINK > with RTB and RTC, hence 3001::/64 & 4001::/64 are directly connected > networks which has been advertised by DR of this network in intra-area > prefix lsa, So only EXIT interface is enough to reach these networks > from any of the router, hence no need of next-hop. > > Regards > Santosh > > On Fri, 7 Jan 2005 21:15:16 +0530, Jayalakshmi G > wrote: > > Hi all, > > I have a doubt in calculating next-hop for network in OSPFv3. > > > > Consider my topology, > > > > RTA > > |e0 > > | > > RTB---------------- RTC > > e1 e1 > > > > RTB e1's interface prefix 3001::3 / 64 > > RTC e1's prefix 3001::9 / 64 > > and > > RTA e0's interface prefix 4000::6 / 64 > > > > For next hop calculation: > > RFC 2740 explains the difference only in calculation for Router and rest > > will be same as 2328. > > RFC 2328 states: > > "If the destination is a directly connected network, or a router which > > connects to the calculating router via a point-to-point interface, no next > > hop IP address is required." > > > > Above lines say, if we are calculating for a directly connected network > then > > we don't need any next hop. > > > > But, in my topology RTA's interface prefix is different from the network > > 3001:: /64. > > So, according to RFC 3001::/64 would seem as directly connected and would > > have no next hop. Actually its next hops should be RTB's and RTC's link > > local addresses. > > > > So, any suggestions as to how should I find the correct next-hops? > > > > Thanks & Regards, > > Jaya > > > > -- > Regards > > Santosh Esale > > Member Technical Staff > > Riverstone Networks India Pvt Ltd. > From owner-ospf@PEACH.EASE.LSOFT.COM Mon Jan 10 13:05:26 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09904 for ; Mon, 10 Jan 2005 13:05:26 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00F3F66A@cherry.ease.lsoft.com>; Mon, 10 Jan 2005 13:05:26 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 52800952 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 10 Jan 2005 13:05:25 -0500 Received: from 131.228.20.27 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 10 Jan 2005 13:05:25 -0500 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0AI5MT15243 for ; Mon, 10 Jan 2005 20:05:23 +0200 (EET) X-Scanned: Mon, 10 Jan 2005 20:03:40 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id j0AI3eFE007887 for ; Mon, 10 Jan 2005 20:03:40 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00BxTjsQ; Mon, 10 Jan 2005 20:03:38 EET Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0AI3XU25429 for ; Mon, 10 Jan 2005 20:03:33 +0200 (EET) Received: from daebe009.NOE.Nokia.com ([10.241.35.109]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 10 Jan 2005 12:00:26 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: draft-ietf-ospf-ospfv3-auth-06.txt Ready for IESG review thread-index: AcT3ETT/Cg679d4iQ0SGrhpX+a13QwALFZ4w X-OriginalArrivalTime: 10 Jan 2005 18:00:26.0571 (UTC) FILETIME=[437FF9B0:01C4F73E] Message-ID: <8D260779A766FB4A9C1739A476F84FA401F79BB3@daebe009.americas.nokia.com> Date: Mon, 10 Jan 2005 12:00:25 -0600 Reply-To: Mailing List Sender: Mailing List From: Mukesh Gupta Subject: Re: draft-ietf-ospf-ospfv3-auth-06.txt Ready for IESG review To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Mitchell, Please read all the text and not just the first paragraph ;) The text does mandate ALL the encryption/authentication algorithms that are MUST in the IPsec mandatory to implement algorithms. So the implementations will be interoperable if they are compliant with this spec. Any platform OS that supports IPsec will have to be compliant with the IPsec mandatory to implement algorithms specfication and then it is just the matter of exposing all those algorithms to the OSPFv3 security configuration. So it is not a big deal to provide all the algorithms that are MUST in IPsec RFCs. Regards Mukesh > -----Original Message----- > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of ext > Erblichs > Sent: Monday, January 10, 2005 4:35 AM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Re: draft-ietf-ospf-ospfv3-auth-06.txt Ready for IESG review >=20 >=20 > Wow, >=20 > > This specification does not mandate specific encryption and > > authentication algorithms because the recommendation for encryption > > and authentication algorithms changes with time as the algorithms > > are broken and more secure algorithms are invented. > >=20 >=20 > Sorry, I am lost with this. The devil in me says that > this means to DELAY" this RFC until a SECURE algorithm > that will NEVER need to be changed is identified. >=20 > OSPF has specified features and is documented and is changed > in the future with later RFCs. >=20 > What is wrong with guaranteeing that at least one algoritm > is specified for interoperability? >=20 > Then as better algorithms are identified, then they are > specified in later docs and superseed earlier algorithms. > Then only the first algorithm is a MUST support and later > algorithms need be a SHOULD supported for later=20 > compatibility. > Right.. > Yes, the full set could be supported, but is probably not > a must, since the first is guaranteed... >=20 > Thus, isn't at least one specified so so algorithm better than > guaranteeing NULL for encryption, etc? >=20 > Mitchell Erblich > ---------------- >=20 > Vishwas Manral wrote: > >=20 > > Hi Mukesh, > >=20 > > I am ok with the text. > >=20 > > Thanks, > > Vishwas > > -----Original Message----- > > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of > > Mukesh Gupta > > Sent: Monday, January 10, 2005 12:09 PM > > To: OSPF@PEACH.EASE.LSOFT.COM > > Subject: Re: draft-ietf-ospf-ospfv3-auth-06.txt Ready for=20 > IESG review > >=20 > > Acee, > >=20 > > Vishwas is right. I don't think we can mandate a specific algorithm > > in the draft and not have to update it in future. > >=20 > > What about we say something like.. > >=20 > > =3D=3D=3D=3D > > This specification does not mandate specific encryption and > > authentication algorithms because the recommendation for encryption > > and authentication algorithms changes with time as the algorithms > > are broken and more secure algorithms are invented. > >=20 > > In order to interoperate with each other, the implementations have > > to have at least one common algorithm that the user can choose to > > use for OSPFv3 security. > >=20 > > The implementation MUST allow the user to choose all the encryption > > and authentication algorithm that are MUST in IPsec mandatory to > > implement algorithms. > >=20 > > The implementation SHOULD allow the user to choose all the=20 > encryption > > and authentication algorithm that are SHOULD in IPsec mandatory to > > implement algorithms. > > =3D=3D=3D=3D > >=20 > > Regards > > Mukesh > >=20 > > > -----Original Message----- > > > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On=20 > Behalf Of ext > > > Vishwas Manral > > > Sent: Sunday, January 09, 2005 8:17 PM > > > To: OSPF@PEACH.EASE.LSOFT.COM > > > Subject: Re: draft-ietf-ospf-ospfv3-auth-06.txt Ready for=20 > IESG review > > > > > > > > > Hi Acee, > > > > > > I agree totally with your views. > > > > > > However examples where algorithms "support has been=20 > changed" are: - > > > > > > " > > > Old Old New > > > Req. RFC(s) Requirement Algorithm (notes) > > > --- ------ ----------- --------- > > > MUST 2406 SHOULD NOT DES-CBC [RFC 2405] (1) > > > MUST 2402 2406 MAY HMAC-MD5-96 [RFC 2403] > > > MUST 2402 2406 MUST HMAC-SHA1-96 [RFC 2404] > > > " > > > > > > Thanks, > > > Vishwas > > > > > > -----Original Message----- > > > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On > > > Behalf Of Acee > > > Lindem > > > Sent: Monday, January 10, 2005 12:49 AM > > > To: OSPF@PEACH.EASE.LSOFT.COM > > > Subject: Re: draft-ietf-ospf-ospfv3-auth-06.txt Ready for=20 > IESG review > > > > > > Mukesh, Vishwas, > > > > > > Here is my take. The document should be written in such > > > a way that it doesn't need to be updated every time the > > > IPSec algorithm > > > de jour changes. > > > > > > However, I also think the document should specify=20 > algorithms with the > > > caveat that they may be updated. IMHO, once an > > > authentication/encrpytion > > > algorithm is deployed, it is unlikely to be withdrawn=20 > from support. > > > Hence, > > > if someone develops a stronger algorithm with lower computational > > > requirements > > > and it becomes the recommended alogorithm, then=20 > implementations will > > > need > > > to support it in ADDITION to what they are currently supporting. > > > > > > Is this possible? Any other opinions? > > > > > > Thanks, > > > Acee > > > > > > > > > Mukesh Gupta wrote: > > > > > > >Vishwas, > > > > > > > >Comments inline.. > > > > > > > > > > > > > > > >>VM> I do not think you talk about encryption at all when you > > > >>talk about > > > >>AH. If you check the documents I have pointed to carefully, > > > >>you will see > > > >>NULL Encryption is a special case of encryption when > > > encryption is not > > > >>used. > > > >> > > > >> > > > > > > > >Would it make more sense if we change the text "NULL encryption" > > > >to "NULL encryption (for ESP) or no encryption (for AH)" ? > > > > > > > > > > > > > > > >>Suresh> We are not a fan of DES either for obvious reasons. > > > But as we > > > >>wanted to start with the weakest algorithm, we started=20 > with DES. We > > > >>wouldn't have to mention DES at all, had IETF/NIST > > > >>suggested DES as "MUST NOT". > > > >>VM> I still don't see a reason why we should talk about=20 > DES at all. > > > >> > > > >> > > > > > > > >I still don't understand why we can't use DES as an=20 > example of a weak > > > >encryption algorithm. > > > > > > > >I would like to hear others' opnion about this ? Acee? > > > > > > > > > > > > > > > >>Suresh> Mukesh and I discussed this again and we agree that > > > >>referring to > > > >>the IPsec algorithm draft should be the better way to go. > > > >>VM> Also not for the authentication you have given the key > > > length and > > > >>for Encryption you have not(so there is anyway a case of > > > >>inconsistency). > > > >> > > > >> > > > > > > > >Yeah but this will be fixed too if we didn't mention any=20 > algorithm > > > >and just pointed to the madatory to implement algos. Right ? > > > > > > > > > > > > > > > >>Suresh> What about the following: > > > >>"Replaying these type of packets can make the router spend some > > > >>resources. Also when the OSPF adjacency is not FULL, replaying > > > >>database description packets can cause disruption in forming the > > > >>adjacency." > > > >>VM> Its not just forming the adjacency Suresh but the=20 > link becoming > > > >>unusable for transit traffic (DoS). In my view you should > > > >>just refer to > > > >>the vulnerabilities draft and probably put a sentence like > > > the above. > > > >> > > > >> > > > > > > > >We do refer to the vulnerabilities draft after the brief=20 > discussion > > > >of the replay vulnerabilities.. So are you ok with putting the > > > >text proposed above and then referring to the=20 > vulerabilities draft ? > > > > > > > > > > > > > > > >>VM> You are right. However I think the aim of the draft is > > > to specify > > > >>how we should use IPSec (guidelines) as well as specify=20 > the default > > > >>behavior(Maybe for all optional parameters we should=20 > specify this). > > > >> > > > >> > > > > > > > >You are right. The aim of this draft is to specify how=20 > OSPFv3 should > > > >use IPsec but I still fail to understand why we need to > > > specify things > > > >that are not related or exposed to OSPF :( > > > > > > > >What exactly do you want to specify about ESN? Do we want to say > > > >that there is no impact of the usage of ESN by the=20 > underlying IPsec > > > >implementation on OSPFv3 security because sequence numbers > > > are ignored > > > >while manual keys are used ? > > > > > > > >Regards > > > >Mukesh > > > > > > > > > > > > > > > >=20 From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jan 11 08:59:32 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24410 for ; Tue, 11 Jan 2005 08:59:32 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.00F40F7C@cherry.ease.lsoft.com>; Tue, 11 Jan 2005 8:59:29 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 52924139 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 11 Jan 2005 08:59:28 -0500 Received: from 64.102.122.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 11 Jan 2005 08:59:27 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 11 Jan 2005 08:59:27 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j0BDxNm4025450 for ; Tue, 11 Jan 2005 08:59:23 -0500 (EST) Received: from [64.102.48.112] (dhcp-64-102-48-112.cisco.com [64.102.48.112]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BEM59400; Tue, 11 Jan 2005 05:59:24 -0800 (PST) User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <8D260779A766FB4A9C1739A476F84FA401F79BB2@daebe009.americas.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <41E3DBBC.809@cisco.com> Date: Tue, 11 Jan 2005 08:59:24 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: draft-ietf-ospf-ospfv3-auth-06.txt Ready for IESG review To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <8D260779A766FB4A9C1739A476F84FA401F79BB2@daebe009.americas.nokia.com> Precedence: list Content-Transfer-Encoding: 7bit Mukesh Gupta wrote: >Acee, > >Vishwas is right. I don't think we can mandate a specific algorithm >in the draft and not have to update it in future. > >What about we say something like.. > >==== >This specification does not mandate specific encryption and >authentication algorithms because the recommendation for encryption >and authentication algorithms changes with time as the algorithms >are broken and more secure algorithms are invented. > >In order to interoperate with each other, the implementations have >to have at least one common algorithm that the user can choose to >use for OSPFv3 security. > >The implementation MUST allow the user to choose all the encryption >and authentication algorithm that are MUST in IPsec mandatory to >implement algorithms. > >The implementation SHOULD allow the user to choose all the encryption >and authentication algorithm that are SHOULD in IPsec mandatory to >implement algorithms. > > Hi Mukesh, I see the point - is there a document that updated regularly that recommends authentication and encryption algorithms for use by routing protocols? Thanks, Acee >==== > >Regards >Mukesh > > > >>-----Original Message----- >>From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of ext >>Vishwas Manral >>Sent: Sunday, January 09, 2005 8:17 PM >>To: OSPF@PEACH.EASE.LSOFT.COM >>Subject: Re: draft-ietf-ospf-ospfv3-auth-06.txt Ready for IESG review >> >> >>Hi Acee, >> >>I agree totally with your views. >> >>However examples where algorithms "support has been changed" are: - >> >>" >> Old Old New >> Req. RFC(s) Requirement Algorithm (notes) >> --- ------ ----------- --------- >> MUST 2406 SHOULD NOT DES-CBC [RFC 2405] (1) >> MUST 2402 2406 MAY HMAC-MD5-96 [RFC 2403] >> MUST 2402 2406 MUST HMAC-SHA1-96 [RFC 2404] >>" >> >>Thanks, >>Vishwas >> >>-----Original Message----- >>From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On >>Behalf Of Acee >>Lindem >>Sent: Monday, January 10, 2005 12:49 AM >>To: OSPF@PEACH.EASE.LSOFT.COM >>Subject: Re: draft-ietf-ospf-ospfv3-auth-06.txt Ready for IESG review >> >>Mukesh, Vishwas, >> >>Here is my take. The document should be written in such >>a way that it doesn't need to be updated every time the >>IPSec algorithm >>de jour changes. >> >>However, I also think the document should specify algorithms with the >>caveat that they may be updated. IMHO, once an >>authentication/encrpytion >>algorithm is deployed, it is unlikely to be withdrawn from support. >>Hence, >>if someone develops a stronger algorithm with lower computational >>requirements >>and it becomes the recommended alogorithm, then implementations will >>need >>to support it in ADDITION to what they are currently supporting. >> >>Is this possible? Any other opinions? >> >>Thanks, >>Acee >> >> >>Mukesh Gupta wrote: >> >> >> >>>Vishwas, >>> >>>Comments inline.. >>> >>> >>> >>> >>> >>>>VM> I do not think you talk about encryption at all when you >>>>talk about >>>>AH. If you check the documents I have pointed to carefully, >>>>you will see >>>>NULL Encryption is a special case of encryption when >>>> >>>> >>encryption is not >> >> >>>>used. >>>> >>>> >>>> >>>> >>>Would it make more sense if we change the text "NULL encryption" >>>to "NULL encryption (for ESP) or no encryption (for AH)" ? >>> >>> >>> >>> >>> >>>>Suresh> We are not a fan of DES either for obvious reasons. >>>> >>>> >> But as we >> >> >>>>wanted to start with the weakest algorithm, we started with DES. We >>>>wouldn't have to mention DES at all, had IETF/NIST >>>>suggested DES as "MUST NOT". >>>>VM> I still don't see a reason why we should talk about DES at all. >>>> >>>> >>>> >>>> >>>I still don't understand why we can't use DES as an example of a weak >>>encryption algorithm. >>> >>>I would like to hear others' opnion about this ? Acee? >>> >>> >>> >>> >>> >>>>Suresh> Mukesh and I discussed this again and we agree that >>>>referring to >>>>the IPsec algorithm draft should be the better way to go. >>>>VM> Also not for the authentication you have given the key >>>> >>>> >>length and >> >> >>>>for Encryption you have not(so there is anyway a case of >>>>inconsistency). >>>> >>>> >>>> >>>> >>>Yeah but this will be fixed too if we didn't mention any algorithm >>>and just pointed to the madatory to implement algos. Right ? >>> >>> >>> >>> >>> >>>>Suresh> What about the following: >>>>"Replaying these type of packets can make the router spend some >>>>resources. Also when the OSPF adjacency is not FULL, replaying >>>>database description packets can cause disruption in forming the >>>>adjacency." >>>>VM> Its not just forming the adjacency Suresh but the link becoming >>>>unusable for transit traffic (DoS). In my view you should >>>>just refer to >>>>the vulnerabilities draft and probably put a sentence like >>>> >>>> >>the above. >> >> >>>> >>>> >>>> >>>> >>>We do refer to the vulnerabilities draft after the brief discussion >>>of the replay vulnerabilities.. So are you ok with putting the >>>text proposed above and then referring to the vulerabilities draft ? >>> >>> >>> >>> >>> >>>>VM> You are right. However I think the aim of the draft is >>>> >>>> >>to specify >> >> >>>>how we should use IPSec (guidelines) as well as specify the default >>>>behavior(Maybe for all optional parameters we should specify this). >>>> >>>> >>>> >>>> >>>You are right. The aim of this draft is to specify how OSPFv3 should >>>use IPsec but I still fail to understand why we need to >>> >>> >>specify things >> >> >>>that are not related or exposed to OSPF :( >>> >>>What exactly do you want to specify about ESN? Do we want to say >>>that there is no impact of the usage of ESN by the underlying IPsec >>>implementation on OSPFv3 security because sequence numbers >>> >>> >>are ignored >> >> >>>while manual keys are used ? >>> >>>Regards >>>Mukesh >>> >>> >>> >>> >>> > > > From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jan 11 10:17:45 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00297 for ; Tue, 11 Jan 2005 10:17:42 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.00F4109B@cherry.ease.lsoft.com>; Tue, 11 Jan 2005 10:17:39 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 52930056 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 11 Jan 2005 10:17:36 -0500 Received: from 202.99.23.227 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 11 Jan 2005 10:07:34 -0500 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm441e45f1d; Tue, 11 Jan 2005 23:10:16 +0800 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jmf41df2e57; Sat, 08 Jan 2005 05:09:38 +0800 Received: from megatron.ietf.org([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm1141df68ad; Sat, 08 Jan 2005 05:09:37 +0800 Received: from megatron.ietf.org([132.151.6.71]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Sat, 08 Jan 2005 05:09:37 +0800 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cn0vS-0004YK-9R; Fri, 07 Jan 2005 15:41:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cn0ti-0003jj-3W for i-d-announce@megatron.ietf.org; Fri, 07 Jan 2005 15:39:50 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21412; Fri, 7 Jan 2005 15:39:47 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: i-d-announce.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: Internet-Drafts@ietf.org X-Auto-Forward: jaglee@people.com.cn jag@kw.com.cn Message-ID: <200501072039.PAA21412@ietf.org> Date: Fri, 7 Jan 2005 15:39:08 -0500 Reply-To: Mailing List Sender: Mailing List From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ospf-cap-05.txt Comments: To: i-d-announce@ietf.org To: OSPF@PEACH.EASE.LSOFT.COM --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF. Title : Extensions to OSPF for Advertising Optional Router Capabilities Author(s) : A. Lindem, et al. Filename : draft-ietf-ospf-cap-05.txt Pages : 14 Date : 2005-1-7 It is useful for routers in an OSPF routing domain to know the capabilities of their neighbors and other routers in the OSPF routing domain. This draft proposes extensions to OSPF for advertising optional router capabilities. A new Router Information (RI) opaque LSA is proposed for this purpose. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-cap-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ospf-cap-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ospf-cap-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-1-7152200.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ospf-cap-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ospf-cap-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-1-7152200.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart-- From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jan 11 17:28:32 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10732 for ; Tue, 11 Jan 2005 17:28:32 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.00F41B18@cherry.ease.lsoft.com>; Tue, 11 Jan 2005 17:28:29 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 52983146 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 11 Jan 2005 17:28:14 -0500 Received: from 131.228.20.21 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 11 Jan 2005 17:28:14 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0BMRLg16822 for ; Wed, 12 Jan 2005 00:27:21 +0200 (EET) X-Scanned: Wed, 12 Jan 2005 00:26:01 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id j0BMQ1nY026929 for ; Wed, 12 Jan 2005 00:26:01 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00nGLvsY; Wed, 12 Jan 2005 00:25:59 EET Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0BLxHU05922 for ; Tue, 11 Jan 2005 23:59:17 +0200 (EET) Received: from daebe009.NOE.Nokia.com ([10.241.35.109]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 11 Jan 2005 15:51:07 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: draft-ietf-ospf-ospfv3-auth-06.txt Ready for IESG review thread-index: AcT35wnVz5DOf7nSRcW8XuXdfEzr5QAQIIxw X-OriginalArrivalTime: 11 Jan 2005 21:51:07.0912 (UTC) FILETIME=[A7FEC080:01C4F827] Message-ID: <8D260779A766FB4A9C1739A476F84FA4026AB84C@daebe009.americas.nokia.com> Date: Tue, 11 Jan 2005 15:51:07 -0600 Reply-To: Mailing List Sender: Mailing List From: Mukesh Gupta Subject: Re: draft-ietf-ospf-ospfv3-auth-06.txt Ready for IESG review To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable > I see the point - is there a document that updated regularly that=20 > recommends authentication and encryption algorithms for use by=20 > routing protocols? I don't know of any that is provides recommendations for routing protocols ! - Mukesh From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jan 11 23:21:03 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04957 for ; Tue, 11 Jan 2005 23:21:03 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00F4215F@cherry.ease.lsoft.com>; Tue, 11 Jan 2005 23:21:04 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 53008737 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 11 Jan 2005 23:21:02 -0500 Received: from 207.217.121.247 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 11 Jan 2005 23:21:02 -0500 Received: from dialup-4.243.128.211.dial1.sanfrancisco1.level3.net ([4.243.128.211] helo=earthlink.net) by pop-a065c32.pas.sa.earthlink.net with esmtp (Exim 3.33 #1) id 1Coa0D-00037R-00 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 11 Jan 2005 20:21:01 -0800 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 (emach0202) X-Accept-Language: en-us MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <41E4A5A8.1000001@earthlink.net> Date: Tue, 11 Jan 2005 20:20:56 -0800 Reply-To: Mailing List Sender: Mailing List From: Richard Ogier Subject: New draft for CDS flooding in MANETs To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hello, I have submitted a new draft describing and evaluating a family of interoperable CDS algorithms for flooding in a MANET extension of OSPF. http://www.ietf.org/internet-drafts/draft-ogier-manet-ospf-extension-02.txt The following bullets summarize the main features of the solution presented in the draft: - The document presents a family of interoperable CDS algorithms, which allow a tradeoff between path optimality and CDS size. Simulation results are presented to show this tradeoff. - The CDS algorithms are based only on 2-hop neighbor information, to provide fast convergence following topology changes. - The CDS algorithms are interoperable because the CDS computed by each algorithm contains a minimal, source-independent CDS called the "Essential" CDS. The Essential CDS can be computed in O(d^2) time, where d is the number of neighbors. - The Essential CDS is very scalable, as shown by the simulation results in Section 10. In a 300 node network with average degree 64 and diameter 5, the Essential CDS consists of only 23 (8%) of the nodes on average. - The Essential CDS provides a minimal, source-independent set of relays for flooding LSAs (or other flooded packets). The flooding procedure also allows source-dependent flooding (using previous-hop information) as an option, if it is desired to flood packets along min-hop paths. - For improved CDS stability, each algorithm in the family has a "persistent" version, in which a router in the CDS remains in the CDS until it becomes redundant. - Generalizes the OSPF concept of a Designated Router (DR) and Backup DR to MANETs. The set of DRs forms a CDS, and the set of DRs and Backup DRs forms a biconnected CDS for robustness. When applied to a broadcast network, the persistent version of each algorithm computes the same DR and Backup DR as OSPF. - Adjacencies are formed only between CDS nodes (DRs and Backup DRs) and their neighbors, as in legacy OSPF. - Provides a flexible choice of which neighbors to include in LSAs, from a minimum set of neighbors adjacent to DRs and Backup DRs, to the full network topology. Regards, Richard From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jan 12 15:41:42 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12386 for ; Wed, 12 Jan 2005 15:41:42 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.00F43327@cherry.ease.lsoft.com>; Wed, 12 Jan 2005 15:41:41 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 53118948 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 12 Jan 2005 15:41:40 -0500 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 12 Jan 2005 15:31:39 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11839; Wed, 12 Jan 2005 15:31:37 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200501122031.PAA11839@ietf.org> Date: Wed, 12 Jan 2005 15:31:37 -0500 Reply-To: Mailing List Sender: Mailing List From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ospf-ospfv3-update-01.txt Comments: To: i-d-announce@ietf.org To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF. Title : OSPF for IPv6 Author(s) : D. Ferguson, et al. Filename : draft-ietf-ospf-ospfv3-update-01.txt Pages : 83 Date : 2005-1-12 This document describes the modifications to OSPF to support version 6 of the Internet Protocol (IPv6). The fundamental mechanisms of OSPF (flooding, DR election, area support, SPF calculations, etc.) remain unchanged. However, some changes have been necessary, either due to changes in protocol semantics between IPv4 and IPv6, or simply to handle the increased address size of IPv6. Changes between OSPF for IPv4 and this document include the following. Addressing semantics have been removed from OSPF packets and the basic LSAs. New LSAs have been created to carry IPv6 addresses and prefixes. OSPF now runs on a per-link basis, instead of on a per-IP-subnet basis. Flooding scope for LSAs has been generalized. Authentication has been removed from the OSPF protocol itself, instead relying on IPv6's Authentication Header and Encapsulating Security Payload. Most packets in OSPF for IPv6 are almost as compact as those in OSPF for IPv4, even with the larger IPv6 addresses. Most fields and packet-size limitations present in OSPF for IPv4 have been relaxed. In addition, option handling has been made more flexible. All of OSPF for IPv4's optional capabilities, including on-demand circuit support, NSSA areas, and the multicast extensions to OSPF (MOSPF) are also supported in OSPF for IPv6. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-update-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ospf-ospfv3-update-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ospf-ospfv3-update-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-1-12155321.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ospf-ospfv3-update-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ospf-ospfv3-update-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-1-12155321.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jan 12 18:14:21 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27503 for ; Wed, 12 Jan 2005 18:14:19 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.00F43756@cherry.ease.lsoft.com>; Wed, 12 Jan 2005 18:14:19 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 53129297 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 12 Jan 2005 18:14:17 -0500 Received: from 171.68.10.86 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 12 Jan 2005 18:14:17 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-4.cisco.com with ESMTP; 12 Jan 2005 15:14:15 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j0CNE6l2006174; Wed, 12 Jan 2005 15:14:07 -0800 (PST) Received: from [192.168.1.101] (che-vpn-cluster-1-181.cisco.com [10.86.240.181]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id PAA09242; Wed, 12 Jan 2005 15:14:09 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/alternative; boundary=Apple-Mail-42-562924577 X-Mailer: Apple Mail (2.619) Message-ID: Date: Wed, 12 Jan 2005 18:14:19 -0500 Reply-To: Mailing List Sender: Mailing List From: JP Vasseur Subject: Fwd: WG Action: Path Computation Element (pce) Comments: To: mpls@ietf.org, idr@ietf.org, ccamp@ops.ietf.org, isis-wg@ietf.org To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list --Apple-Mail-42-562924577 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit FYI, JP. Begin forwarded message: > From: The IESG > Date: January 12, 2005 3:39:31 PM EST > To: IETF-Announce@ietf.org > Cc: pce@ietf.org, Adrian Farrel , JP Vasseur > > Subject: WG Action: Path Computation Element (pce) > > A new IETF working group has been formed in the Routing Area. For > additional > information, please contact the Area Directors or the WG Chairs. > > Path Computation Element (pce) > ================================ > > Current Status: Active Working Group > > Chair(s): > Adrian Farrel > JP Vasseur > > Routing Area Director(s): > Bill Fenner > Alex Zinin > > Routing Area Advisor: > Alex Zinin > > Mailing Lists: > General Discussion: pce@ietf.org > To Subscribe: pce-request@ietf.org > In Body: subscribe pce > Archive: http://www.ietf.org/mail-archive/web/pce/ > > Description of Working Group: > > The PCE Working Group is chartered to specify a Path Computation > Element (PCE) > based architecture for the computation of paths for MPLS and GMPLS > Traffic > Engineering LSPs. > > In this architecture path computation does not occur on the head-end > (ingress) > LSR, but on some other path computation entity that may physically not > be > located on the head-end LSR. > > The PCE WG will work on application of this model within a single > domain > or within a small group of domains (where a domain is a layer, IGP area > or Autonomous System with limited visibility from the head-end LSR). > At this time, applying this model to large groups of domains such as > the > Internet is not thought to be possible, and the PCE WG will not spend > energy on that topic. > > The WG will specify a protocol for communication between LSRs (termed > Path > Computation Clients - PCCs) and PCEs, and between cooperating PCEs. > This > protocol will be capable of representing requests for path computation > including a full set of constraints, will be able to return multiple > paths, and > will include security mechanisms such as authentication and > confidentiality. > > The WG will determine requirements for extensions to existing routing > and > signaling protocols in support of PCE discovery and signaling of > inter-domain > paths. Candidate protocols for extensions are RSVP-TE, OSPF-TE, > ISIS-TE and > BGP. Any necessary extensions will be produced in collaboration with > the > Working Groups responsible for the protocols. > > The Working Group will also work on the definition of metrics to > evaluate path quality, scalability, responsiveness and robustness of > path computation models. > > Work Items: > > - Functional specification of MPLS and GMPLS Traffic Engineered LSP > path > computation models involving Path Computation Element(s). This > includes the case of computing the paths of intra and inter-domain > TE LSPs. Such path computation includes the generation of primary, > protection and recovery paths, as well as computations for > (local/global) > reoptimization and load balancing. The WG will address the inter-area > (single IGP domain) scenario first. WG progress will be evaluated > before > inter-AS related work is started. > > - Specification of the PCE-based architecture. > > - Specification of requirements and protocol extensions related to > the policy, and security aspects of PCE-based path computation > involving > PCEs of multiple administrative entities. > > - In cooperation with protocol specific Working Group (OSPF, ISIS, IDR, > MPLS, CCAMP), development of routing (OSPF, ISIS, BGP) and LSP > signaling (RSVP-TE) extensions required to support PCE-based path > computation models. > > - Specification of techniques in support of PCE discovery within and > across domains. Where such techniques result in the extensions of > existing protocols (e.g., OSPF, ISIS or BGP), this work will be done in > conjunction with the appropriate WGs. > > - Specification of a new communication protocol for use between a PCC > and a PCE, and between PCEs. A single protocol will be selected from > among candidates that include the existing protocols defined in other > WGs. > > - Definition of objective metrics to evaluate various criteria such as > the measurement of path quality, response time, robustness and > scalability of path computation models. > > Review of the document "Requirements for path computation element in > GMPLS inter-domain networks" produced by the CCAMP WG. > > > Goals and Milestones: > > Feb 05: Submit first draft of PCE architecture document > > Feb 05: Submit first draft of PCE discovery requirements and protocol > extensions documents > > Apr 05: Submit first draft of the PCE communication protocol > requirements > > May 05: Submit first draft of the definition of objective metrics > > Jul 05: Submit first draft of the PCE communication protocol > specification > > Aug 05: Submit PCE architecture specification to the IESG to be > considered as Informational RFC > > Nov 05: Submit first draft of applicability statement (describing the > processes > and procedures for the use of the PCE architecture, protocols > and protocol extensions for inter-area MPLS and GMPLS Traffic > Engineering) > > Nov 05: Submit first draft of the MIB module for the PCE protocol > > Dec 05: Submit PCE communication protocol requirements to the IESG to > be > considered as an Informational RFC > > Dec 05: Submit PCE discovery protocol extensions specifications to the > IESG to be considered as a Proposed Standard > > Dec 05: Submit PCE communication protocol specification to the IESG to > be considered as a Proposed Standard > > Feb 06: Submit the applicability and metrics documents to the IESG to > be > considered as Informational RFC > > Feb 06: Evaluate WG progress, recharter or close. > --Apple-Mail-42-562924577 Content-Type: text/enriched; charset=US-ASCII Content-Transfer-Encoding: 7bit FYI, JP. Begin forwarded message: Helvetica0000,0000,0000From: HelveticaThe IESG < 0000,0000,0000Date: January 12, 2005 3:39:31 PM EST 0000,0000,0000To: IETF-Announce@ietf.org 0000,0000,0000Cc: pce@ietf.org, Adrian Farrel <, JP Vasseur < 0000,0000,0000Subject: WG Action: Path Computation Element (pce) A new IETF working group has been formed in the Routing Area. For additional information, please contact the Area Directors or the WG Chairs. Path Computation Element (pce) ================================ Current Status: Active Working Group Chair(s): Adrian Farrel < JP Vasseur < Routing Area Director(s): Bill Fenner < Alex Zinin < Routing Area Advisor: Alex Zinin < Mailing Lists: General Discussion: pce@ietf.org To Subscribe: pce-request@ietf.org In Body: subscribe pce Archive: http://www.ietf.org/mail-archive/web/pce/ Description of Working Group: The PCE Working Group is chartered to specify a Path Computation Element (PCE) based architecture for the computation of paths for MPLS and GMPLS Traffic Engineering LSPs. In this architecture path computation does not occur on the head-end (ingress) LSR, but on some other path computation entity that may physically not be located on the head-end LSR. The PCE WG will work on application of this model within a single domain or within a small group of domains (where a domain is a layer, IGP area or Autonomous System with limited visibility from the head-end LSR). At this time, applying this model to large groups of domains such as the Internet is not thought to be possible, and the PCE WG will not spend energy on that topic. The WG will specify a protocol for communication between LSRs (termed Path Computation Clients - PCCs) and PCEs, and between cooperating PCEs. This protocol will be capable of representing requests for path computation including a full set of constraints, will be able to return multiple paths, and will include security mechanisms such as authentication and confidentiality. The WG will determine requirements for extensions to existing routing and signaling protocols in support of PCE discovery and signaling of inter-domain paths. Candidate protocols for extensions are RSVP-TE, OSPF-TE, ISIS-TE and BGP. Any necessary extensions will be produced in collaboration with the Working Groups responsible for the protocols. The Working Group will also work on the definition of metrics to evaluate path quality, scalability, responsiveness and robustness of path computation models. Work Items: - Functional specification of MPLS and GMPLS Traffic Engineered LSP path computation models involving Path Computation Element(s). This includes the case of computing the paths of intra and inter-domain TE LSPs. Such path computation includes the generation of primary, protection and recovery paths, as well as computations for (local/global) reoptimization and load balancing. The WG will address the inter-area (single IGP domain) scenario first. WG progress will be evaluated before inter-AS related work is started. - Specification of the PCE-based architecture. - Specification of requirements and protocol extensions related to the policy, and security aspects of PCE-based path computation involving PCEs of multiple administrative entities. - In cooperation with protocol specific Working Group (OSPF, ISIS, IDR, MPLS, CCAMP), development of routing (OSPF, ISIS, BGP) and LSP signaling (RSVP-TE) extensions required to support PCE-based path computation models. - Specification of techniques in support of PCE discovery within and across domains. Where such techniques result in the extensions of existing protocols (e.g., OSPF, ISIS or BGP), this work will be done in conjunction with the appropriate WGs. - Specification of a new communication protocol for use between a PCC and a PCE, and between PCEs. A single protocol will be selected from among candidates that include the existing protocols defined in other WGs. - Definition of objective metrics to evaluate various criteria such as the measurement of path quality, response time, robustness and scalability of path computation models. Review of the document "Requirements for path computation element in GMPLS inter-domain networks" produced by the CCAMP WG. Goals and Milestones: Feb 05: Submit first draft of PCE architecture document Feb 05: Submit first draft of PCE discovery requirements and protocol extensions documents Apr 05: Submit first draft of the PCE communication protocol requirements May 05: Submit first draft of the definition of objective metrics Jul 05: Submit first draft of the PCE communication protocol specification Aug 05: Submit PCE architecture specification to the IESG to be considered as Informational RFC Nov 05: Submit first draft of applicability statement (describing the processes and procedures for the use of the PCE architecture, protocols and protocol extensions for inter-area MPLS and GMPLS Traffic Engineering) Nov 05: Submit first draft of the MIB module for the PCE protocol Dec 05: Submit PCE communication protocol requirements to the IESG to be considered as an Informational RFC Dec 05: Submit PCE discovery protocol extensions specifications to the IESG to be considered as a Proposed Standard Dec 05: Submit PCE communication protocol specification to the IESG to be considered as a Proposed Standard Feb 06: Submit the applicability and metrics documents to the IESG to be considered as Informational RFC Feb 06: Evaluate WG progress, recharter or close. --Apple-Mail-42-562924577-- From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jan 12 18:44:25 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29900 for ; Wed, 12 Jan 2005 18:44:23 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.00F436B6@cherry.ease.lsoft.com>; Wed, 12 Jan 2005 18:44:21 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 53130778 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 12 Jan 2005 18:44:19 -0500 Received: from 63.113.148.10 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 12 Jan 2005 18:34:19 -0500 Received: from mgate1.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id PAA01785; Wed, 12 Jan 2005 15:34:17 -0800 (PST) Received: (from daemon@localhost) by mgate1.riverstonenet.com (8.13.1/8.13.1) id j0CNYGhZ014560; Wed, 12 Jan 2005 15:34:16 -0800 (PST) X-Authentication-Warning: mgate1.riverstonenet.com: Processed by daemon with -C /etc/mail/sendmail-simple.cf Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by mgate1.riverstonenet.com (8.13.1/8.13.1) with ESMTP id j0CNY4pP014483; Wed, 12 Jan 2005 15:34:06 -0800 (PST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CorkZ-0002kV-0R; Wed, 12 Jan 2005 18:18:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CorhR-0000jP-DL; Wed, 12 Jan 2005 18:14:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27578; Wed, 12 Jan 2005 18:14:46 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CorvX-0002wr-Th; Wed, 12 Jan 2005 18:29:24 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-4.cisco.com with ESMTP; 12 Jan 2005 15:14:15 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j0CNE6l2006174; Wed, 12 Jan 2005 15:14:07 -0800 (PST) Received: from [192.168.1.101] (che-vpn-cluster-1-181.cisco.com [10.86.240.181]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id PAA09242; Wed, 12 Jan 2005 15:14:09 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v619) X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 94902b99ee6852833c9a2b680a1de4d3 X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0288458767==" Errors-To: mpls-bounces@ietf.org X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=failed version=3.0.1 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on mgate1.riverstonenet.com Message-ID: Date: Wed, 12 Jan 2005 18:14:19 -0500 Reply-To: Mailing List Sender: Mailing List From: JP Vasseur Subject: [mpls] Fwd: WG Action: Path Computation Element (pce) Comments: To: mpls@ietf.org, idr@ietf.org, ccamp@ops.ietf.org, isis-wg@ietf.org To: OSPF@PEACH.EASE.LSOFT.COM --===============0288458767== Content-Type: multipart/alternative; boundary=Apple-Mail-42-562924577 --Apple-Mail-42-562924577 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit FYI, JP. Begin forwarded message: > From: The IESG > Date: January 12, 2005 3:39:31 PM EST > To: IETF-Announce@ietf.org > Cc: pce@ietf.org, Adrian Farrel , JP Vasseur > > Subject: WG Action: Path Computation Element (pce) > > A new IETF working group has been formed in the Routing Area. For > additional > information, please contact the Area Directors or the WG Chairs. > > Path Computation Element (pce) > ================================ > > Current Status: Active Working Group > > Chair(s): > Adrian Farrel > JP Vasseur > > Routing Area Director(s): > Bill Fenner > Alex Zinin > > Routing Area Advisor: > Alex Zinin > > Mailing Lists: > General Discussion: pce@ietf.org > To Subscribe: pce-request@ietf.org > In Body: subscribe pce > Archive: http://www.ietf.org/mail-archive/web/pce/ > > Description of Working Group: > > The PCE Working Group is chartered to specify a Path Computation > Element (PCE) > based architecture for the computation of paths for MPLS and GMPLS > Traffic > Engineering LSPs. > > In this architecture path computation does not occur on the head-end > (ingress) > LSR, but on some other path computation entity that may physically not > be > located on the head-end LSR. > > The PCE WG will work on application of this model within a single > domain > or within a small group of domains (where a domain is a layer, IGP area > or Autonomous System with limited visibility from the head-end LSR). > At this time, applying this model to large groups of domains such as > the > Internet is not thought to be possible, and the PCE WG will not spend > energy on that topic. > > The WG will specify a protocol for communication between LSRs (termed > Path > Computation Clients - PCCs) and PCEs, and between cooperating PCEs. > This > protocol will be capable of representing requests for path computation > including a full set of constraints, will be able to return multiple > paths, and > will include security mechanisms such as authentication and > confidentiality. > > The WG will determine requirements for extensions to existing routing > and > signaling protocols in support of PCE discovery and signaling of > inter-domain > paths. Candidate protocols for extensions are RSVP-TE, OSPF-TE, > ISIS-TE and > BGP. Any necessary extensions will be produced in collaboration with > the > Working Groups responsible for the protocols. > > The Working Group will also work on the definition of metrics to > evaluate path quality, scalability, responsiveness and robustness of > path computation models. > > Work Items: > > - Functional specification of MPLS and GMPLS Traffic Engineered LSP > path > computation models involving Path Computation Element(s). This > includes the case of computing the paths of intra and inter-domain > TE LSPs. Such path computation includes the generation of primary, > protection and recovery paths, as well as computations for > (local/global) > reoptimization and load balancing. The WG will address the inter-area > (single IGP domain) scenario first. WG progress will be evaluated > before > inter-AS related work is started. > > - Specification of the PCE-based architecture. > > - Specification of requirements and protocol extensions related to > the policy, and security aspects of PCE-based path computation > involving > PCEs of multiple administrative entities. > > - In cooperation with protocol specific Working Group (OSPF, ISIS, IDR, > MPLS, CCAMP), development of routing (OSPF, ISIS, BGP) and LSP > signaling (RSVP-TE) extensions required to support PCE-based path > computation models. > > - Specification of techniques in support of PCE discovery within and > across domains. Where such techniques result in the extensions of > existing protocols (e.g., OSPF, ISIS or BGP), this work will be done in > conjunction with the appropriate WGs. > > - Specification of a new communication protocol for use between a PCC > and a PCE, and between PCEs. A single protocol will be selected from > among candidates that include the existing protocols defined in other > WGs. > > - Definition of objective metrics to evaluate various criteria such as > the measurement of path quality, response time, robustness and > scalability of path computation models. > > Review of the document "Requirements for path computation element in > GMPLS inter-domain networks" produced by the CCAMP WG. > > > Goals and Milestones: > > Feb 05: Submit first draft of PCE architecture document > > Feb 05: Submit first draft of PCE discovery requirements and protocol > extensions documents > > Apr 05: Submit first draft of the PCE communication protocol > requirements > > May 05: Submit first draft of the definition of objective metrics > > Jul 05: Submit first draft of the PCE communication protocol > specification > > Aug 05: Submit PCE architecture specification to the IESG to be > considered as Informational RFC > > Nov 05: Submit first draft of applicability statement (describing the > processes > and procedures for the use of the PCE architecture, protocols > and protocol extensions for inter-area MPLS and GMPLS Traffic > Engineering) > > Nov 05: Submit first draft of the MIB module for the PCE protocol > > Dec 05: Submit PCE communication protocol requirements to the IESG to > be > considered as an Informational RFC > > Dec 05: Submit PCE discovery protocol extensions specifications to the > IESG to be considered as a Proposed Standard > > Dec 05: Submit PCE communication protocol specification to the IESG to > be considered as a Proposed Standard > > Feb 06: Submit the applicability and metrics documents to the IESG to > be > considered as Informational RFC > > Feb 06: Evaluate WG progress, recharter or close. > --Apple-Mail-42-562924577 Content-Type: text/enriched; charset=US-ASCII Content-Transfer-Encoding: 7bit FYI, JP. Begin forwarded message: Helvetica0000,0000,0000From: HelveticaThe IESG < 0000,0000,0000Date: January 12, 2005 3:39:31 PM EST 0000,0000,0000To: IETF-Announce@ietf.org 0000,0000,0000Cc: pce@ietf.org, Adrian Farrel <, JP Vasseur < 0000,0000,0000Subject: WG Action: Path Computation Element (pce) A new IETF working group has been formed in the Routing Area. For additional information, please contact the Area Directors or the WG Chairs. Path Computation Element (pce) ================================ Current Status: Active Working Group Chair(s): Adrian Farrel < JP Vasseur < Routing Area Director(s): Bill Fenner < Alex Zinin < Routing Area Advisor: Alex Zinin < Mailing Lists: General Discussion: pce@ietf.org To Subscribe: pce-request@ietf.org In Body: subscribe pce Archive: http://www.ietf.org/mail-archive/web/pce/ Description of Working Group: The PCE Working Group is chartered to specify a Path Computation Element (PCE) based architecture for the computation of paths for MPLS and GMPLS Traffic Engineering LSPs. In this architecture path computation does not occur on the head-end (ingress) LSR, but on some other path computation entity that may physically not be located on the head-end LSR. The PCE WG will work on application of this model within a single domain or within a small group of domains (where a domain is a layer, IGP area or Autonomous System with limited visibility from the head-end LSR). At this time, applying this model to large groups of domains such as the Internet is not thought to be possible, and the PCE WG will not spend energy on that topic. The WG will specify a protocol for communication between LSRs (termed Path Computation Clients - PCCs) and PCEs, and between cooperating PCEs. This protocol will be capable of representing requests for path computation including a full set of constraints, will be able to return multiple paths, and will include security mechanisms such as authentication and confidentiality. The WG will determine requirements for extensions to existing routing and signaling protocols in support of PCE discovery and signaling of inter-domain paths. Candidate protocols for extensions are RSVP-TE, OSPF-TE, ISIS-TE and BGP. Any necessary extensions will be produced in collaboration with the Working Groups responsible for the protocols. The Working Group will also work on the definition of metrics to evaluate path quality, scalability, responsiveness and robustness of path computation models. Work Items: - Functional specification of MPLS and GMPLS Traffic Engineered LSP path computation models involving Path Computation Element(s). This includes the case of computing the paths of intra and inter-domain TE LSPs. Such path computation includes the generation of primary, protection and recovery paths, as well as computations for (local/global) reoptimization and load balancing. The WG will address the inter-area (single IGP domain) scenario first. WG progress will be evaluated before inter-AS related work is started. - Specification of the PCE-based architecture. - Specification of requirements and protocol extensions related to the policy, and security aspects of PCE-based path computation involving PCEs of multiple administrative entities. - In cooperation with protocol specific Working Group (OSPF, ISIS, IDR, MPLS, CCAMP), development of routing (OSPF, ISIS, BGP) and LSP signaling (RSVP-TE) extensions required to support PCE-based path computation models. - Specification of techniques in support of PCE discovery within and across domains. Where such techniques result in the extensions of existing protocols (e.g., OSPF, ISIS or BGP), this work will be done in conjunction with the appropriate WGs. - Specification of a new communication protocol for use between a PCC and a PCE, and between PCEs. A single protocol will be selected from among candidates that include the existing protocols defined in other WGs. - Definition of objective metrics to evaluate various criteria such as the measurement of path quality, response time, robustness and scalability of path computation models. Review of the document "Requirements for path computation element in GMPLS inter-domain networks" produced by the CCAMP WG. Goals and Milestones: Feb 05: Submit first draft of PCE architecture document Feb 05: Submit first draft of PCE discovery requirements and protocol extensions documents Apr 05: Submit first draft of the PCE communication protocol requirements May 05: Submit first draft of the definition of objective metrics Jul 05: Submit first draft of the PCE communication protocol specification Aug 05: Submit PCE architecture specification to the IESG to be considered as Informational RFC Nov 05: Submit first draft of applicability statement (describing the processes and procedures for the use of the PCE architecture, protocols and protocol extensions for inter-area MPLS and GMPLS Traffic Engineering) Nov 05: Submit first draft of the MIB module for the PCE protocol Dec 05: Submit PCE communication protocol requirements to the IESG to be considered as an Informational RFC Dec 05: Submit PCE discovery protocol extensions specifications to the IESG to be considered as a Proposed Standard Dec 05: Submit PCE communication protocol specification to the IESG to be considered as a Proposed Standard Feb 06: Submit the applicability and metrics documents to the IESG to be considered as Informational RFC Feb 06: Evaluate WG progress, recharter or close. --Apple-Mail-42-562924577-- --===============0288458767== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============0288458767==-- From owner-ospf@PEACH.EASE.LSOFT.COM Thu Jan 13 06:57:19 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00200 for ; Thu, 13 Jan 2005 06:57:19 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.00F44593@cherry.ease.lsoft.com>; Thu, 13 Jan 2005 6:57:20 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 53216803 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 13 Jan 2005 06:57:18 -0500 Received: from 62.241.162.32 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 13 Jan 2005 06:57:18 -0500 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by ranger.systems.pipex.net (Postfix) with ESMTP id 97148E0003BF; Thu, 13 Jan 2005 11:57:17 +0000 (GMT) Received: from Puppy ([212.43.203.220] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 13 Jan 2005 11:57:16 +0000 References: <41DF53F4.8050704@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 13 Jan 2005 11:57:17.0163 (UTC) FILETIME=[073D6BB0:01C4F967] Message-ID: <02bd01c4f967$2d604c90$b4cb2bd4@Puppy> Date: Thu, 13 Jan 2005 11:43:45 -0000 Reply-To: Mailing List Sender: Mailing List From: Adrian Farrel Subject: Re: WG Last Call for "Extensions to OSPF for Advertising Optional Router" Comments: cc: Acee Lindem To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi, I have some comments about this draft (which I support). Section 1. It is premature to cite this technique as a method for PCS discovery (by the way, the term is now PCE not PCS). The need for *any* discovery technique is still an item for the PCE working group. Assuming a need is derived, the mechanism would still be up to the PCE working group. While the PCE WG may choose to use the mechanism defined in this draft to discover PCEs, this draft MUST NOT prejudge this item. Therefore, please remove all reference to PCS from the first bullet of section 1. [Actually, I would suggest streamlining the draft by striking the whole first paragraph (and both bullets) of section 1.] Section 2. "If a router does not advertise this LSA, it does not imply that the router does not support one or more of the defined capabilities." Surely this is an issue for the RFC/I-D that defines each option TLV, and in the case of the OSPF Router Capabilities TLV it is an issue for the RFC/I-D that defines each option bit? What your current text does is prevent future uses of this LSA from identifying unambiguously whether a router supports a specific new function. [See draft-ietf-mpls-rsvpte-attributes for handling of this issue in RSVP-TE signaling.] Section 2. "The Router Information LSA will have an Opaque type of 4 and Opaque ID of 0." Present tense, please. Section 2.1 "The first defined TLV in the body of an RI opaque LSA is the Router Capabilities TLV." I suspect this means exactly what it says, but it will be misinterpretted! It will be assumed to mean that the first TLV in the LSA MUST be the Router Capabilities TLV. Is it relevant that this is the first TLV to be defined? OTOH, you should state clearly if there are any oredering rules about TLVs. You go on to say... "A router advertising an RI opaque LSA SHOULD include the Router Capabilities TLV..." Why is this "SHOULD" not "MUST"? If there are valid reasons to leave it out, then it is not even as strong as "SHOULD". Section 2.1 " Length A 16 bit field that indicates the length of the value portion in bytes. Its set to N x 4 octets. N starts from 1 and can be increased when there is a need. Each 4 octets are referred to as a capability flag." This text is confused! - Either talk about bytes or octets - s/Its/It's/ - "N x 4 octets" is open to easy misinterpretation. Should we fill in the value N? Don't you mean that the length field must be a multiple of four? - "N starts from 1" means that the minimum valid length is four. Why not say this? - Why is it relevant that "N can be increased where there is a need"? - It is unusual to refer to a collection of 32 bits as a single flag. Surely each bit is a flag? I don't think it is helpful to consider these blocks of flags. Don't you just have an endless stream of defined capabilities bits encoded in a value that is rounded up to 32 bits by the insertion of undefined bits? Section 2.1 " Value This comprises one or more capability flags. For each 4" The figure shows a field called "Capabilities" not "Value". Section 2.1 "The Router Capabilities TLV MAY be followed by optional TLV's that further specify a capability." Now, *this* seems to say that the RC TLV might be expected to be first. Section 2.2 You should not list the bits defined in other documents. I assume that you would like this I-D to become an RFC sometime soon! I think that what you are trying to do is provide a pre-IANA registry. Get the WG chairs to put this on the Routing Area web pages or the OSPF WG pages. In any case, please do not define a bit for PCE discovery in this I-D (see my first point). I am also worried by the definition of four reserved bits. I assume that these are reserved because of some proprietary or old usage. Why is it necessary to have reserved bits in the first version of an RFC? Section 2.3 type 11 (AS-scoped) opaque LSA may be flooded. If a type 11 opaque LSA is chosen, the originating router should also advertise type 10 LSA(s) into any attached NSSA/stub area(s). An OSPF router MAY s/should/SHOULD/ Section 2.3 "TLV flooding scope rules will be specified on a per-TLV basis." What does this actually mean? I don't find a per-TLV flooding scope definition for the RC TLV. Are you saying that the definition of a TLV in a separate document MUST specifiy how the TLV will be flooded and that the flooding of a particular TLV may vary despite the flooding scope of the LSA in which it is carried? Or are you saying that the definition of each TLV must state for which LSA scope flooding the TLV is valid? If the latter, you need to add this information point to the IANA tracking in section 5. Scetion 5. The IANA section is far from complete. You can't expect IANA to trawl the draft for the values you have defined. Are you asking IANA to manage the allocation of RC TLV bits? Do you also need to specify that the assignment of bits in the RC TLV is subject to OSPF WG review? Section 6.2 [OPAQUE] should be normative Cheers, Adrian From owner-ospf@PEACH.EASE.LSOFT.COM Thu Jan 13 08:34:07 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08555 for ; Thu, 13 Jan 2005 08:34:05 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00F44514@cherry.ease.lsoft.com>; Thu, 13 Jan 2005 8:34:00 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 53221992 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 13 Jan 2005 08:33:57 -0500 Received: from 147.28.0.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 13 Jan 2005 08:23:57 -0500 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1Cp4x9-000HVm-Q5; Thu, 13 Jan 2005 13:23:56 +0000 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <41DF53F4.8050704@cisco.com> <02bd01c4f967$2d604c90$b4cb2bd4@Puppy> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <41E6766A.8090703@psg.com> Date: Thu, 13 Jan 2005 14:23:54 +0100 Reply-To: Mailing List Sender: Mailing List From: dimitri papadimitriou Subject: Re: WG Last Call for "Extensions to OSPF for Advertising Optional Router" Comments: To: Adrian Farrel To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <02bd01c4f967$2d604c90$b4cb2bd4@Puppy> Precedence: list Content-Transfer-Encoding: 7bit hi adrian, all, 1. concerning the comment on section 2.2 if the bits remain defined in this document - then as bit 7 references only TE (RFC 3630) i think there is a value in defining a specific bit for the support of the GMPLS OSPF-TE extensions support (hint: this should not mean that bit 7 is for MPLS-TE and the latter (the proposed new bit) for non-MPLS TE, as GMPLS extensions defines a superset of MPLS-TE) 2. would it be possible to clarify the following statement "For existing OSPF capabilities, this advertisement will be used primarily for informational purposes." it appears both in section 1. and 2. thanks, - dimitri. Adrian Farrel wrote: > Hi, > > I have some comments about this draft (which I support). > > Section 1. > It is premature to cite this technique as a method for PCS discovery (by > the way, the term is now PCE not PCS). The need for *any* discovery > technique is still an item for the PCE working group. Assuming a need is > derived, the mechanism would still be up to the PCE working group. > While the PCE WG may choose to use the mechanism defined in this draft to > discover PCEs, this draft MUST NOT prejudge this item. > Therefore, please remove all reference to PCS from the first bullet of > section 1. > > [Actually, I would suggest streamlining the draft by striking the whole > first paragraph (and both bullets) of section 1.] > > > Section 2. > "If a > router does not advertise this LSA, it does not imply that the router > does not support one or more of the defined capabilities." > Surely this is an issue for the RFC/I-D that defines each option TLV, and > in the case of the OSPF Router Capabilities TLV it is an issue for the > RFC/I-D that defines each option bit? > What your current text does is prevent future uses of this LSA from > identifying unambiguously whether a router supports a specific new > function. > > [See draft-ietf-mpls-rsvpte-attributes for handling of this issue in > RSVP-TE signaling.] > > > Section 2. > "The Router Information LSA will have an Opaque type of 4 and Opaque > ID of 0." > Present tense, please. > > Section 2.1 > "The first defined TLV in the body of an RI opaque LSA is the Router > Capabilities TLV." > I suspect this means exactly what it says, but it will be misinterpretted! > It will be assumed to mean that the first TLV in the LSA MUST be the > Router Capabilities TLV. > Is it relevant that this is the first TLV to be defined? > OTOH, you should state clearly if there are any oredering rules about > TLVs. > > You go on to say... > "A router advertising an RI opaque LSA SHOULD > include the Router Capabilities TLV..." > Why is this "SHOULD" not "MUST"? If there are valid reasons to leave it > out, then it is not even as strong as "SHOULD". > > Section 2.1 > " Length A 16 bit field that indicates the length of the value > portion in bytes. Its set to N x 4 octets. N starts > from 1 and can be increased when there is a need. Each 4 > octets are referred to as a capability flag." > This text is confused! > - Either talk about bytes or octets > - s/Its/It's/ > - "N x 4 octets" is open to easy misinterpretation. Should we fill in the > value N? > Don't you mean that the length field must be a multiple of four? > - "N starts from 1" means that the minimum valid length is four. Why not > say this? > - Why is it relevant that "N can be increased where there is a need"? > - It is unusual to refer to a collection of 32 bits as a single flag. > Surely each bit is a flag? > I don't think it is helpful to consider these blocks of flags. Don't you > just have an > endless stream of defined capabilities bits encoded in a value that is > rounded up to > 32 bits by the insertion of undefined bits? > > Section 2.1 > " Value This comprises one or more capability flags. For each 4" > The figure shows a field called "Capabilities" not "Value". > > Section 2.1 > "The Router Capabilities TLV MAY be followed by optional TLV's that > further specify a capability." > Now, *this* seems to say that the RC TLV might be expected to be first. > > Section 2.2 > You should not list the bits defined in other documents. > I assume that you would like this I-D to become an RFC sometime soon! > I think that what you are trying to do is provide a pre-IANA registry. Get > the WG chairs to put this on the Routing Area web pages or the OSPF WG > pages. > > In any case, please do not define a bit for PCE discovery in this I-D (see > my first point). > > I am also worried by the definition of four reserved bits. I assume that > these are reserved because of some proprietary or old usage. Why is it > necessary to have reserved bits in the first version of an RFC? > > Section 2.3 > type 11 (AS-scoped) opaque LSA may be flooded. If a type 11 opaque > LSA is chosen, the originating router should also advertise type 10 > LSA(s) into any attached NSSA/stub area(s). An OSPF router MAY > s/should/SHOULD/ > > > Section 2.3 > "TLV flooding > scope rules will be specified on a per-TLV basis." > What does this actually mean? > I don't find a per-TLV flooding scope definition for the RC TLV. > Are you saying that the definition of a TLV in a separate document MUST > specifiy how the TLV will be flooded and that the flooding of a particular > TLV may vary despite the flooding scope of the LSA in which it is carried? > Or are you saying that the definition of each TLV must state for which LSA > scope flooding the TLV is valid? > If the latter, you need to add this information point to the IANA tracking > in section 5. > > > Scetion 5. > The IANA section is far from complete. You can't expect IANA to trawl the > draft for the values you have defined. > Are you asking IANA to manage the allocation of RC TLV bits? > Do you also need to specify that the assignment of bits in the RC TLV is > subject to OSPF WG review? > > > Section 6.2 > [OPAQUE] should be normative > > > Cheers, > Adrian > > . > From owner-ospf@PEACH.EASE.LSOFT.COM Thu Jan 13 14:20:14 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05437 for ; Thu, 13 Jan 2005 14:20:13 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00F44CA5@cherry.ease.lsoft.com>; Thu, 13 Jan 2005 14:20:13 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 53256482 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 13 Jan 2005 14:20:11 -0500 Received: from 65.205.166.188 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 13 Jan 2005 14:20:11 -0500 Received: from dc1laptop (unknown [172.16.24.103]) by jera.movaz.com (Postfix) with SMTP id 478C014736 for ; Thu, 13 Jan 2005 14:20:11 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Message-ID: Date: Thu, 13 Jan 2005 14:20:10 -0500 Reply-To: Mailing List Sender: Mailing List From: Dan Dovolsky Subject: packet looping problem To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit Gentlemen, I have a question about packet looping problem and would be very appreciate if anyone could help on this. Consider please following topology N2 10.0.1.0/24 | N1 |------10.0.1.3-- R3 (loopback = 10.0.2.3/32) |----R1 --- R2--10.0.1.1----| | (lpbk = 10.0.2.2/32) |------10.0.1.4-- R4 (loopback = 10.0.2.4/32) R1 has static route 10.0.2.0/24 with nexthop to R2. R2 has default static route 0.0.0.0/0 with nexthop to R1 From N1 someone sends packets to the address 10.0.2.5 (which is not exist on any node). R1 sends this packet to R2, R2 checks that this address is not in its routing table and sends packet back to R1 using default route. Packet is bouncing between R1 and R2 until it’s TTL expired. During this packet looping access to N2 network is almost blocked. This situation has caused by enabled “forwarding” option of BSD IP stack. My question is if they’re any wide implemented solutions/fixes for this problem. The solution comes to my mind is to check before packet forwarding the new resolved destination MAC address and if it’s equal to the original packet source MAC address just drop the packet. Is there any problem with that? Thanks very much, Dan Dovolsky. Regards, Dan Dovolsky. Office: 703-847-2438 ddovolsky@movaz.com From owner-ospf@PEACH.EASE.LSOFT.COM Thu Jan 13 14:53:07 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08731 for ; Thu, 13 Jan 2005 14:53:06 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.00F44E07@cherry.ease.lsoft.com>; Thu, 13 Jan 2005 14:53:07 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 53259794 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 13 Jan 2005 14:53:05 -0500 Received: from 64.47.51.130 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 13 Jan 2005 14:53:05 -0500 Received: from dgoodspeedpc ([172.22.184.130] unverified) by exchange.timetra.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 13 Jan 2005 11:53:00 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-OriginalArrivalTime: 13 Jan 2005 19:53:00.0387 (UTC) FILETIME=[7C53C330:01C4F9A9] Message-ID: <002801c4f9a9$79e4bf00$f703a8c0@eng.timetra.com> Date: Thu, 13 Jan 2005 11:52:55 -0800 Reply-To: Mailing List Sender: Mailing List From: Don Goodspeed Subject: Re: packet looping problem Comments: To: ddovolsky@movaz.com To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 8bit Dan, What you've described is not an OSPF issue but a native IP issue so while some on this list might be able to answer, I would voice that this is the wrong forum since this should be confined to OSPF issues. Maybe the Routing Area WG (rtgwg) would be a better place to post this. -don -----Original Message----- From: owner-ospf@PEACH.EASE.LSOFT.COM [mailto:owner-ospf@PEACH.EASE.LSOFT.COM]On Behalf Of Dan Dovolsky Sent: Thursday, January 13, 2005 11:20 AM To: OSPF Subject: packet looping problem Gentlemen, I have a question about packet looping problem and would be very appreciate if anyone could help on this. Consider please following topology N2 10.0.1.0/24 | N1 |------10.0.1.3-- R3 (loopback = 10.0.2.3/32) |----R1 --- R2--10.0.1.1----| | (lpbk = 10.0.2.2/32) |------10.0.1.4-- R4 (loopback = 10.0.2.4/32) R1 has static route 10.0.2.0/24 with nexthop to R2. R2 has default static route 0.0.0.0/0 with nexthop to R1 From N1 someone sends packets to the address 10.0.2.5 (which is not exist on any node). R1 sends this packet to R2, R2 checks that this address is not in its routing table and sends packet back to R1 using default route. Packet is bouncing between R1 and R2 until it’s TTL expired. During this packet looping access to N2 network is almost blocked. This situation has caused by enabled “forwarding” option of BSD IP stack. My question is if they’re any wide implemented solutions/fixes for this problem. The solution comes to my mind is to check before packet forwarding the new resolved destination MAC address and if it’s equal to the original packet source MAC address just drop the packet. Is there any problem with that? Thanks very much, Dan Dovolsky. Regards, Dan Dovolsky. Office: 703-847-2438 ddovolsky@movaz.com From owner-ospf@PEACH.EASE.LSOFT.COM Thu Jan 13 15:12:25 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10412 for ; Thu, 13 Jan 2005 15:12:25 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00F44D24@cherry.ease.lsoft.com>; Thu, 13 Jan 2005 15:12:25 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 53262517 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 13 Jan 2005 15:12:24 -0500 Received: from 158.130.70.79 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 13 Jan 2005 15:12:24 -0500 Received: from ee.upenn.edu (M367PC1.CIS.upenn.edu [158.130.12.199]) (authenticated bits=0) by stag.seas.upenn.edu (8.12.10/8.12.10) with ESMTP id j0DKCNWx026275 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 13 Jan 2005 15:12:23 -0500 User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 References: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by stag.seas.upenn.edu id j0DKCNWx026275 Message-ID: <41E6D57D.4060103@ee.upenn.edu> Date: Thu, 13 Jan 2005 15:09:33 -0500 Reply-To: Mailing List Sender: Mailing List From: Roch Guerin Subject: Re: packet looping problem To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: quoted-printable Dan, As was pointed out in another reply, this is not an OSPF specific problem. Typically this kind of issue would be dealt with through the use of=20 "discard entries" that are added to the routing table for all the active=20 address ranges that the router has (see, Section 11.1, p. 111, or RFC=20 2328), and one could argue that in your example 10.0.2.0/24 is in fact=20 an active address range of R2. The problem here is that R1 learns about=20 it through configuration and not from R2 advertising a summary route.=20 But then if you are going to be using static routes, I can definitely=20 come up with lots and lots of looping scenarios if they are mis-used ;-}=20 In general, you'll find references to the dangers of over-lapping=20 address ranges in pretty much any routing book. Roch >Gentlemen, > >I have a question about packet looping problem and would be very appreci= ate >if anyone could help on this. > >Consider please following topology > > N2 10.0.1.0/24 >| N1 |------10.0.1.3-- R3 (loopback =3D 10.0.2.3/= 32) >|----R1 --- R2--10.0.1.1----| >| (lpbk =3D 10.0.2.2/32) |------10.0.1.4-- R4 (loopback =3D 10.0.2.= 4/32) > > >R1 has static route 10.0.2.0/24 with nexthop to R2. >R2 has default static route 0.0.0.0/0 with nexthop to R1 > >>From N1 someone sends packets to the address 10.0.2.5 (which is not exi= st on >any node). R1 sends this packet to R2, R2 checks that this address is no= t in >its routing table and sends packet back to R1 using default route. Packe= t is >bouncing between R1 and R2 until it=92s TTL expired. >During this packet looping access to N2 network is almost blocked. >This situation has caused by enabled =93forwarding=94 option of BSD IP s= tack. My >question is if they=92re any wide implemented solutions/fixes for this >problem. > >The solution comes to my mind is to check before packet forwarding the n= ew >resolved destination MAC address and if it=92s equal to the original pac= ket >source MAC address just drop the packet. Is there any problem with that? > >Thanks very much, >Dan Dovolsky. > >Regards, >Dan Dovolsky. > >Office: 703-847-2438 >ddovolsky@movaz.com > =20 > From owner-ospf@PEACH.EASE.LSOFT.COM Thu Jan 13 16:47:26 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25918 for ; Thu, 13 Jan 2005 16:47:26 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.00F44F06@cherry.ease.lsoft.com>; Thu, 13 Jan 2005 16:47:24 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 53270171 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 13 Jan 2005 16:47:12 -0500 Received: from 171.68.10.87 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 13 Jan 2005 16:37:12 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-5.cisco.com with ESMTP; 13 Jan 2005 13:37:19 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j0DLb7vl020737 for ; Thu, 13 Jan 2005 13:37:08 -0800 (PST) Received: from bboninw2k02 (sjc-bbonin-vpn3.cisco.com [10.25.94.196]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id NAA27503 for ; Thu, 13 Jan 2005 13:37:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcT5pPhce7QF9elMRmqPSBEL/y3LdAAEnoEg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-ID: <200501132137.NAA27503@franklin.cisco.com> Date: Thu, 13 Jan 2005 15:37:09 -0600 Reply-To: Mailing List Sender: Mailing List From: Brad Bonin Subject: Re: packet looping problem To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit Dan, a quick resolution would be to not use statics on both sides:-) Reply direct if needed... Brad brad@cisco.com -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Dan Dovolsky Sent: Thursday, January 13, 2005 1:20 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: packet looping problem Gentlemen, I have a question about packet looping problem and would be very appreciate if anyone could help on this. Consider please following topology N2 10.0.1.0/24 | N1 |------10.0.1.3-- R3 (loopback = 10.0.2.3/32) |----R1 --- R2--10.0.1.1----| | (lpbk = 10.0.2.2/32) |------10.0.1.4-- R4 (loopback = |10.0.2.4/32) R1 has static route 10.0.2.0/24 with nexthop to R2. R2 has default static route 0.0.0.0/0 with nexthop to R1 >From N1 someone sends packets to the address 10.0.2.5 (which is not >exist on any node). R1 sends this packet to R2, R2 checks that this address is not in its routing table and sends packet back to R1 using default route. Packet is bouncing between R1 and R2 until it's TTL expired. During this packet looping access to N2 network is almost blocked. This situation has caused by enabled "forwarding" option of BSD IP stack. My question is if they're any wide implemented solutions/fixes for this problem. The solution comes to my mind is to check before packet forwarding the new resolved destination MAC address and if it's equal to the original packet source MAC address just drop the packet. Is there any problem with that? Thanks very much, Dan Dovolsky. Regards, Dan Dovolsky. Office: 703-847-2438 ddovolsky@movaz.com From owner-ospf*ospf-archive**LISTS*-IETF*-ORG@PEACH.EASE.LSOFT.COM Fri Jan 14 06:32:53 2005 Received: from grape.ease.lsoft.com (grape.ease.lsoft.com [209.119.1.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02341 for ; Fri, 14 Jan 2005 06:32:53 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (209.119.1.45) by grape.ease.lsoft.com (LSMTP for OpenVMS v1.1b) with SMTP id <2.00537DF0@grape.ease.lsoft.com>; Fri, 14 Jan 2005 6:32:51 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 53352575 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 14 Jan 2005 06:32:50 -0500 Received: from 209.119.0.34 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 14 Jan 2005 06:22:43 -0500 Received: from PEACH.EASE.LSOFT.COM (209.119.1.45) by grape.ease.lsoft.com (LSMTP for OpenVMS v1.1b) with SMTP id <0.00537BA8@grape.ease.lsoft.com>; Fri, 14 Jan 2005 6:22:44 -0500 Message-ID: Date: Fri, 14 Jan 2005 06:22:43 -0500 Reply-To: Mailing List Sender: Mailing List From: Deepak Dandekar Subject: Re: FW: Last call comments on draft-ietf-ospf-shortcut-abr-02.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Hello, Can someone, please, let me know the existing state of the draft. I tried searching for it on the OSPF IETF web-page, (http://www.ietf.org/html. charters/ospf-charter.html) but could not get any information. thanks, Deepak. On Thu, 1 Feb 2001 17:24:03 -0500, Moy, John wrote: >-----Original Message----- >From: Moy, John >Sent: Thursday, February 01, 2001 5:23 PM >To: 'Alex Zinin' >Subject: RE: Last call comments on draft-ietf-ospf-shortcut-abr-02.txt > > >Alex- > >Here is an attempt to state a couple of my previous >comments more clearly. > >>> 1. In Step 2 of the memo's Section 3.3 (staring at the >>> bottom of page 8), I think that instead of >>> "and the ABR has a backbone connection", you really >>> meant "and the calculating router has a backbone connection". >>> However, I don't think that either is right; instead the phrase >>> should simply be deleted. You shouldn't be doing the >>> shortcut behavior unless all ABRs in the area agree, regardless >>> of whether they are connected to the backbone, or you >>> risk permanent routing loops. > >>The idea is to shortcut through non-bb areas by default if >>the calculating router has no bb attachment (and hence does not >>announce the routes any further, and does not form a loop, so it >>is safe), and not to shortcut through them by default if >>the calculating box has a bb attachment. > >It is OK to automatically request to shortcut if you have no >backbone connection. But if the other ABRs attached to the area >don't agree (as evidenced by bit S in their router-LSAs being >clear), you shouldn't *perform* the shortcut calculation. If you >do, you risk creating permanent routing loops. You can see this by >modifying some of the network diagrams that you used to demonstrate >the black holes created by non-backbone-attached ABRs. In some >topologies, doing a shortcut without cooperation of the other ABRs >turns the black hole into a routing loop. > >>> 2. For the same reason, Step 3 of RFC 2328's Section 16.3 >>> should be modified (you text starting at the end of page >>> 9) only if ShortcutCapability is TRUE for the area >>> whose summary-LSA is being considered. > >>Do you mean make sure the functionality is not changed >>if the summary-LSAs are considered because of the area's >>TransitCapability flag? > >Yes. This gets back to the previous point. You can't start >shortcutting (that is, changing the behavior of Section 16.3) >unless all the other ABRs agree (ShortcutCapability >is TRUE). > >John From owner-ospf@PEACH.EASE.LSOFT.COM Fri Jan 14 08:20:09 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12935 for ; Fri, 14 Jan 2005 08:20:07 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00F46119@cherry.ease.lsoft.com>; Fri, 14 Jan 2005 8:20:04 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 53373352 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 14 Jan 2005 08:20:01 -0500 Received: from 64.102.122.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 14 Jan 2005 08:20:01 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 14 Jan 2005 08:20:01 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j0EDJxW0023691 for ; Fri, 14 Jan 2005 08:19:59 -0500 (EST) Received: from [10.82.217.211] (rtp-vpn3-465.cisco.com [10.82.217.211]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BEO90277; Fri, 14 Jan 2005 05:19:58 -0800 (PST) User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <41E7C6FE.4070205@cisco.com> Date: Fri, 14 Jan 2005 08:19:58 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: FW: Last call comments on draft-ietf-ospf-shortcut-abr-02.txt To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit Deepak Dandekar wrote: >Hello, >Can someone, please, let me know the existing state of the draft. I tried >searching for it on the OSPF IETF web-page, (http://www.ietf.org/html. >charters/ospf-charter.html) but could not get any information. > > Hi Deepak, This draft expired without making it through the standards process. I seem to remember the idea was somewhat interesting but there must not have been a strong enough requirement. You can find expired drafts at: http://www.watersprings.org/ Hope this helps, Acee >thanks, >Deepak. > >On Thu, 1 Feb 2001 17:24:03 -0500, Moy, John >wrote: > > > >>-----Original Message----- >>From: Moy, John >>Sent: Thursday, February 01, 2001 5:23 PM >>To: 'Alex Zinin' >>Subject: RE: Last call comments on draft-ietf-ospf-shortcut-abr-02.txt >> >> >>Alex- >> >>Here is an attempt to state a couple of my previous >>comments more clearly. >> >> >> >>>>1. In Step 2 of the memo's Section 3.3 (staring at the >>>>bottom of page 8), I think that instead of >>>>"and the ABR has a backbone connection", you really >>>>meant "and the calculating router has a backbone connection". >>>>However, I don't think that either is right; instead the phrase >>>>should simply be deleted. You shouldn't be doing the >>>>shortcut behavior unless all ABRs in the area agree, regardless >>>>of whether they are connected to the backbone, or you >>>>risk permanent routing loops. >>>> >>>> >>>The idea is to shortcut through non-bb areas by default if >>>the calculating router has no bb attachment (and hence does not >>>announce the routes any further, and does not form a loop, so it >>>is safe), and not to shortcut through them by default if >>>the calculating box has a bb attachment. >>> >>> >>It is OK to automatically request to shortcut if you have no >>backbone connection. But if the other ABRs attached to the area >>don't agree (as evidenced by bit S in their router-LSAs being >>clear), you shouldn't *perform* the shortcut calculation. If you >>do, you risk creating permanent routing loops. You can see this by >>modifying some of the network diagrams that you used to demonstrate >>the black holes created by non-backbone-attached ABRs. In some >>topologies, doing a shortcut without cooperation of the other ABRs >>turns the black hole into a routing loop. >> >> >> >>>>2. For the same reason, Step 3 of RFC 2328's Section 16.3 >>>>should be modified (you text starting at the end of page >>>>9) only if ShortcutCapability is TRUE for the area >>>>whose summary-LSA is being considered. >>>> >>>> >>>Do you mean make sure the functionality is not changed >>>if the summary-LSAs are considered because of the area's >>>TransitCapability flag? >>> >>> >>Yes. This gets back to the previous point. You can't start >>shortcutting (that is, changing the behavior of Section 16.3) >>unless all the other ABRs agree (ShortcutCapability >>is TRUE). >> >>John >> >> > > > From owner-ospf@PEACH.EASE.LSOFT.COM Mon Jan 17 23:47:44 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26526 for ; Mon, 17 Jan 2005 23:47:43 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.00F4C825@cherry.ease.lsoft.com>; Mon, 17 Jan 2005 23:47:42 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 53847848 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 17 Jan 2005 23:47:39 -0500 Received: from 64.102.122.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 17 Jan 2005 23:47:39 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 18 Jan 2005 00:01:32 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j0I4lbW0003911; Mon, 17 Jan 2005 23:47:37 -0500 (EST) Received: from [10.82.242.106] (rtp-vpn2-618.cisco.com [10.82.242.106]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BEQ55698; Mon, 17 Jan 2005 20:47:35 -0800 (PST) User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <41DF53F4.8050704@cisco.com> <02bd01c4f967$2d604c90$b4cb2bd4@Puppy> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <41EC94E7.6080508@cisco.com> Date: Mon, 17 Jan 2005 23:47:35 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: WG Last Call for "Extensions to OSPF for Advertising Optional Router" Comments: To: Adrian Farrel To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <02bd01c4f967$2d604c90$b4cb2bd4@Puppy> Precedence: list Content-Transfer-Encoding: 7bit Hi Adrian, Thanks for your comments. I will post another revision for WG review. See responses below. Adrian Farrel wrote: >Hi, > >I have some comments about this draft (which I support). > >Section 1. >It is premature to cite this technique as a method for PCS discovery (by >the way, the term is now PCE not PCS). The need for *any* discovery >technique is still an item for the PCE working group. Assuming a need is >derived, the mechanism would still be up to the PCE working group. >While the PCE WG may choose to use the mechanism defined in this draft to >discover PCEs, this draft MUST NOT prejudge this item. >Therefore, please remove all reference to PCS from the first bullet of >section 1. > >[Actually, I would suggest streamlining the draft by striking the whole >first paragraph (and both bullets) of section 1.] > > I've discussed with JP and I will make some modifications here. > >Section 2. > "If a > router does not advertise this LSA, it does not imply that the router > does not support one or more of the defined capabilities." >Surely this is an issue for the RFC/I-D that defines each option TLV, and >in the case of the OSPF Router Capabilities TLV it is an issue for the >RFC/I-D that defines each option bit? >What your current text does is prevent future uses of this LSA from >identifying unambiguously whether a router supports a specific new >function. > > It is not meant to do this. It is meant to allow existing capabilities to be advertised for informational purposes while allowing new capabilities to make use of this LSA as the sole mechanism for advertisement. I'll look into rewording. >[See draft-ietf-mpls-rsvpte-attributes for handling of this issue in >RSVP-TE signaling.] > > I'll take a look this draft. > >Section 2. > "The Router Information LSA will have an Opaque type of 4 and Opaque > ID of 0." >Present tense, please. > > Will fix. >Section 2.1 > "The first defined TLV in the body of an RI opaque LSA is the Router > Capabilities TLV." >I suspect this means exactly what it says, but it will be misinterpretted! >It will be assumed to mean that the first TLV in the LSA MUST be the >Router Capabilities TLV. >Is it relevant that this is the first TLV to be defined? >OTOH, you should state clearly if there are any oredering rules about >TLVs. > >You go on to say... > "A router advertising an RI opaque LSA SHOULD > include the Router Capabilities TLV..." >Why is this "SHOULD" not "MUST"? If there are valid reasons to leave it >out, then it is not even as strong as "SHOULD". > > Will discuss with the other authors. My take is that this is a "MUST". >Section 2.1 > " Length A 16 bit field that indicates the length of the value > portion in bytes. Its set to N x 4 octets. N starts > from 1 and can be increased when there is a need. Each 4 > octets are referred to as a capability flag." >This text is confused! >- Either talk about bytes or octets >- s/Its/It's/ >- "N x 4 octets" is open to easy misinterpretation. Should we fill in the >value N? > Don't you mean that the length field must be a multiple of four? >- "N starts from 1" means that the minimum valid length is four. Why not >say this? >- Why is it relevant that "N can be increased where there is a need"? >- It is unusual to refer to a collection of 32 bits as a single flag. >Surely each bit is a flag? > I don't think it is helpful to consider these blocks of flags. Don't you >just have an > endless stream of defined capabilities bits encoded in a value that is >rounded up to > 32 bits by the insertion of undefined bits? > > Will look at rewording - we always have wanted the flags to be added in increments of 4 octets. >Section 2.1 > " Value This comprises one or more capability flags. For each 4" >The figure shows a field called "Capabilities" not "Value". > > Ok, >Section 2.1 > "The Router Capabilities TLV MAY be followed by optional TLV's that > further specify a capability." >Now, *this* seems to say that the RC TLV might be expected to be first. > > Again, my take is that the RC TLV should be required. >Section 2.2 >You should not list the bits defined in other documents. >I assume that you would like this I-D to become an RFC sometime soon! >I think that what you are trying to do is provide a pre-IANA registry. Get >the WG chairs to put this on the Routing Area web pages or the OSPF WG >pages. > >In any case, please do not define a bit for PCE discovery in this I-D (see >my first point). > > Ok. >I am also worried by the definition of four reserved bits. I assume that >these are reserved because of some proprietary or old usage. Why is it >necessary to have reserved bits in the first version of an RFC? > > AFAIK, there is no proprietary usage of these bits. They are simply reserved. >Section 2.3 > type 11 (AS-scoped) opaque LSA may be flooded. If a type 11 opaque > LSA is chosen, the originating router should also advertise type 10 > LSA(s) into any attached NSSA/stub area(s). An OSPF router MAY >s/should/SHOULD/ > > >Section 2.3 > "TLV flooding > scope rules will be specified on a per-TLV basis." >What does this actually mean? >I don't find a per-TLV flooding scope definition for the RC TLV. >Are you saying that the definition of a TLV in a separate document MUST >specifiy how the TLV will be flooded and that the flooding of a particular >TLV may vary despite the flooding scope of the LSA in which it is carried? >Or are you saying that the definition of each TLV must state for which LSA >scope flooding the TLV is valid? > > The latter. >If the latter, you need to add this information point to the IANA tracking >in section 5. > > Ok. > >Scetion 5. >The IANA section is far from complete. You can't expect IANA to trawl the >draft for the values you have defined. > > Ok - will beef up. >Are you asking IANA to manage the allocation of RC TLV bits? > > No. >Do you also need to specify that the assignment of bits in the RC TLV is >subject to OSPF WG review? > > Yes. > >Section 6.2 >[OPAQUE] should be normative > > Ok. > >Cheers, >Adrian > > > From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jan 18 08:20:18 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21372 for ; Tue, 18 Jan 2005 08:20:18 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.00F4CF5A@cherry.ease.lsoft.com>; Tue, 18 Jan 2005 8:20:18 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 53911815 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 18 Jan 2005 08:20:15 -0500 Received: from 62.241.163.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 18 Jan 2005 08:20:15 -0500 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by astro.systems.pipex.net (Postfix) with ESMTP id C3516E000264; Tue, 18 Jan 2005 13:20:15 +0000 (GMT) Received: from Puppy ([212.43.203.214] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 18 Jan 2005 13:20:09 +0000 References: <41DF53F4.8050704@cisco.com> <02bd01c4f967$2d604c90$b4cb2bd4@Puppy> <41EC94E7.6080508@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 18 Jan 2005 13:20:10.0152 (UTC) FILETIME=[6F701280:01C4FD60] Message-ID: <02a201c4fd60$9aa6b1c0$e7cb2bd4@Puppy> Date: Tue, 18 Jan 2005 13:09:35 -0000 Reply-To: Mailing List Sender: Mailing List From: Adrian Farrel Subject: Re: WG Last Call for "Extensions to OSPF for Advertising Optional Router" Comments: To: Acee Lindem To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Thanks Acee, All of your responses look good. Comments in line. Adrian > >Section 2.2 > >I am also worried by the definition of four reserved bits. I assume that > >these are reserved because of some proprietary or old usage. Why is it > >necessary to have reserved bits in the first version of an RFC? > > AFAIK, there is no proprietary usage of these bits. They are simply > reserved. Then shall we make them unassigned? That is, available for IANA to assign for other uses. > >Scetion 5. > > >Are you asking IANA to manage the allocation of RC TLV bits? > > No. Why not? (It was a loaded question :-) How will you track which bits have been allocated and make sure that we don't get two RFCs using the same bit for different purposes? From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jan 19 05:49:00 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00115 for ; Wed, 19 Jan 2005 05:48:59 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.00F4E8D2@cherry.ease.lsoft.com>; Wed, 19 Jan 2005 5:48:54 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 54047289 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 19 Jan 2005 05:48:52 -0500 Received: from 63.197.255.158 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 19 Jan 2005 05:48:52 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4FE15.C9E86CFC" Thread-Topic: draft-manral-ospf-router-lsa-unknown-type-02 thread-index: AcT+FZ3E49ywwBnsSJSbwPkQ0dt8SQ== Message-ID: Date: Wed, 19 Jan 2005 02:57:06 -0800 Reply-To: Mailing List Sender: Mailing List From: Vishwas Manral Subject: draft-manral-ospf-router-lsa-unknown-type-02 To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This is a multi-part message in MIME format. ------_=_NextPart_001_01C4FE15.C9E86CFC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi folks, =20 I would want to progress the following draft to completion: - http://www.ietf.org/internet-drafts/draft-manral-ospf-router-lsa-unknown -type-02.txt =20 Would we want to leave it as it is, make it an individual submission to IESG, or first make a WG draft and submit then it to IESG? =20 Thanks, Vishwas =20 ------_=_NextPart_001_01C4FE15.C9E86CFC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi folks,

 

I would want to progress the following draft to = completion: -

http://www.ietf.org/internet-drafts/draft-manral-osp= f-router-lsa-unknown-type-02.txt

 

Would we want to leave it as it is, make it an = individual submission to IESG, or first make a WG draft and submit then it to = IESG?

 

Thanks,

Vishwas

 

------_=_NextPart_001_01C4FE15.C9E86CFC-- From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jan 19 21:22:39 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21026 for ; Wed, 19 Jan 2005 21:22:39 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.00F4F8D4@cherry.ease.lsoft.com>; Wed, 19 Jan 2005 21:22:38 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 54168635 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 19 Jan 2005 21:22:35 -0500 Received: from 64.102.122.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 19 Jan 2005 21:22:35 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 19 Jan 2005 21:22:35 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j0K2MVW2009848 for ; Wed, 19 Jan 2005 21:22:33 -0500 (EST) Received: from [10.82.240.219] (rtp-vpn2-219.cisco.com [10.82.240.219]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BES15679; Wed, 19 Jan 2005 18:22:30 -0800 (PST) User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <41EF15E6.8000108@cisco.com> Date: Wed, 19 Jan 2005 21:22:30 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: draft-manral-ospf-router-lsa-unknown-type-02 To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit Vishwas Manral wrote: > Hi folks, > > > > I would want to progress the following draft to completion: - > > http://www.ietf.org/internet-drafts/draft-manral-ospf-router-lsa-unknown-type-02.txt > > > > Would we want to leave it as it is, make it an individual submission > to IESG, or first make a WG draft and submit then it to IESG? > Any opinions on this draft? Speaking as a WG member I'd support it. We'll schedule 5-10 minutes in Minneapolis to discuss. Thanks, Acee > > > Thanks, > > Vishwas > > > From owner-ospf@PEACH.EASE.LSOFT.COM Fri Jan 21 08:36:07 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09588 for ; Fri, 21 Jan 2005 08:36:06 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00F5319F@cherry.ease.lsoft.com>; Fri, 21 Jan 2005 8:35:59 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 54422466 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 21 Jan 2005 08:35:54 -0500 Received: from 63.197.255.158 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 21 Jan 2005 08:35:54 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: draft-manral-ospf-router-lsa-unknown-type-02 thread-index: AcT+mD5mPU7x/3D8SN2OOg1iZUaJDQBJuGQA Message-ID: Date: Fri, 21 Jan 2005 05:44:13 -0800 Reply-To: Mailing List Sender: Mailing List From: Vishwas Manral Subject: Re: draft-manral-ospf-router-lsa-unknown-type-02 To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Thanks a lot Acee. As this is more like a bug fix, would the category be Standard Track or Informational? Thanks again, Vishwas -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Acee Lindem Sent: Thursday, January 20, 2005 7:53 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: draft-manral-ospf-router-lsa-unknown-type-02 Vishwas Manral wrote: > Hi folks, > > =20 > > I would want to progress the following draft to completion: - > > http://www.ietf.org/internet-drafts/draft-manral-ospf-router-lsa-unknown -type-02.txt > > =20 > > Would we want to leave it as it is, make it an individual submission=20 > to IESG, or first make a WG draft and submit then it to IESG? > Any opinions on this draft? Speaking as a WG member I'd support it. We'll schedule 5-10 minutes in=20 Minneapolis to discuss. Thanks, Acee > > Thanks, > Vishwas > From owner-ospf@PEACH.EASE.LSOFT.COM Fri Jan 21 09:20:07 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13530 for ; Fri, 21 Jan 2005 09:20:06 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.00F53503@cherry.ease.lsoft.com>; Fri, 21 Jan 2005 9:20:06 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 54433096 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 21 Jan 2005 09:20:03 -0500 Received: from 64.102.122.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 21 Jan 2005 09:20:03 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 21 Jan 2005 09:27:56 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j0LEK1W0029313 for ; Fri, 21 Jan 2005 09:20:02 -0500 (EST) Received: from [10.82.240.219] (rtp-vpn2-219.cisco.com [10.82.240.219]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BET16470; Fri, 21 Jan 2005 06:19:59 -0800 (PST) User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <41F10F8F.8030405@cisco.com> Date: Fri, 21 Jan 2005 09:19:59 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: draft-manral-ospf-router-lsa-unknown-type-02 To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit Vishwas Manral wrote: >Thanks a lot Acee. > >As this is more like a bug fix, would the category be Standard Track or >Informational? > > I guess standards track would be better and than I'd include the change in the OSPFv3 update. Since we are going from undefined to defined behavior we have to be careful as to how the draft is ultimately worded. Could you prepare a couple slides for the Minneapolis IETF? If you are not going to be there, I could certainly present it. >Thanks again, >Vishwas >-----Original Message----- >From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Acee >Lindem >Sent: Thursday, January 20, 2005 7:53 AM >To: OSPF@PEACH.EASE.LSOFT.COM >Subject: Re: draft-manral-ospf-router-lsa-unknown-type-02 > >Vishwas Manral wrote: > > > >>Hi folks, >> >> >> >>I would want to progress the following draft to completion: - >> >> >> >> >http://www.ietf.org/internet-drafts/draft-manral-ospf-router-lsa-unknown >-type-02.txt > > >> >> >>Would we want to leave it as it is, make it an individual submission >>to IESG, or first make a WG draft and submit then it to IESG? >> >> >> >Any opinions on this draft? > >Speaking as a WG member I'd support it. We'll schedule 5-10 minutes in >Minneapolis to >discuss. > >Thanks, >Acee > > >>Thanks, >>Vishwas >> >> >> > > > From owner-ospf@PEACH.EASE.LSOFT.COM Fri Jan 21 23:24:51 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20355 for ; Fri, 21 Jan 2005 23:24:51 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00F55722@cherry.ease.lsoft.com>; Fri, 21 Jan 2005 23:24:51 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 54544392 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 21 Jan 2005 23:24:49 -0500 Received: from 204.176.140.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 21 Jan 2005 23:24:49 -0500 Received: from manikantan (dsl-TN-007.240.247.61.touchtelindia.net [61.247.240.7] (may be forged)) (authenticated bits=0) by mail2.webindia.com (8.13.1/8.13.1) with ESMTP id j0M4RmEf032159 for ; Fri, 21 Jan 2005 20:27:59 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 thread-index: AcT/xMSVSDvx1Rh7RVKnDUoPXRI1tgAdHsfw X-IBIS-MailScanner-Information: Please contact the ISP for more information X-IBIS-MailScanner: Found to be clean X-MailScanner-From: manis@net-o2.com Message-ID: <200501220427.j0M4RmEf032159@mail2.webindia.com> Date: Sat, 22 Jan 2005 09:54:28 +0530 Reply-To: Mailing List Sender: Mailing List From: Manikantan Srinivasan Organization: Net-O2 Technologies Subject: Re: draft-manral-ospf-router-lsa-unknown-type-02 To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <41F10F8F.8030405@cisco.com> Precedence: list Content-Transfer-Encoding: 7bit Hello Acee, Vishwas I understand the ability to add new link types to the router LSA is to enable new implementations/applications to propagate new link types and their associated additional link information. This information will be used (currently) by few implementation and others need to ignore. Hence the clarification / addition to the standard. Do we need to add new link types to the router LSA? Can't we use the Opaque LSAs to pass the additional/new information? Best regards mani # -----Original Message----- # From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On # Behalf Of Acee Lindem # Sent: Friday, January 21, 2005 7:50 PM # To: OSPF@PEACH.EASE.LSOFT.COM # Subject: Re: draft-manral-ospf-router-lsa-unknown-type-02 # # Vishwas Manral wrote: # # >Thanks a lot Acee. # > # >As this is more like a bug fix, would the category be # Standard Track or # >Informational? # > # > # I guess standards track would be better and than I'd include # the change in the OSPFv3 update. # Since we are going from undefined to defined behavior we have # to be careful as to how the draft is ultimately worded. # # Could you prepare a couple slides for the Minneapolis IETF? # If you are not going to be there, I could certainly present it. # # >Thanks again, # >Vishwas # >-----Original Message----- # >From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On # Behalf Of Acee # >Lindem # >Sent: Thursday, January 20, 2005 7:53 AM # >To: OSPF@PEACH.EASE.LSOFT.COM # >Subject: Re: draft-manral-ospf-router-lsa-unknown-type-02 # > # >Vishwas Manral wrote: # > # > # > # >>Hi folks, # >> # >> # >> # >>I would want to progress the following draft to completion: - # >> # >> # >> # >> # >http://www.ietf.org/internet-drafts/draft-manral-ospf-router- # lsa-unknow # >n # >-type-02.txt # > # > # >> # >> # >>Would we want to leave it as it is, make it an individual # submission # >>to IESG, or first make a WG draft and submit then it to IESG? # >> # >> # >> # >Any opinions on this draft? # > # >Speaking as a WG member I'd support it. We'll schedule 5-10 # minutes in # >Minneapolis to discuss. # > # >Thanks, # >Acee # > # > # >>Thanks, # >>Vishwas # >> # >> # >> # > # > # > # From owner-ospf@PEACH.EASE.LSOFT.COM Sat Jan 22 04:59:41 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23288 for ; Sat, 22 Jan 2005 04:59:39 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.00F55AF6@cherry.ease.lsoft.com>; Sat, 22 Jan 2005 4:59:33 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 54566737 for OSPF@PEACH.EASE.LSOFT.COM; Sat, 22 Jan 2005 04:59:31 -0500 Received: from 203.199.83.245 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sat, 22 Jan 2005 04:59:30 -0500 Received: (qmail 27220 invoked by uid 510); 22 Jan 2005 10:01:05 -0000 Received: from unknown (203.126.136.220) by rediffmail.com via HTTP; 22 jan 2005 10:01:04 -0000 MIME-Version: 1.0 Content-type: multipart/alternative; boundary="Next_1106388064---0-203.199.83.245-27168" Message-ID: <20050122100105.27219.qmail@mailweb33.rediffmail.com> Date: Sat, 22 Jan 2005 10:01:05 -0000 Reply-To: Mailing List Sender: Mailing List From: Vivek Dubey Subject: Re: draft-manral-ospf-router-lsa-unknown-type-02 To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This is a multipart mime message --Next_1106388064---0-203.199.83.245-27168 Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Vishwas,=0A=0ADraft doesnt say anything about the case "All links have unkn= own link type" =A0in the Router Lsa. Such an information should be left for= opaque LSAs.=0A=0AFurther -=0AUnknown : 1) Extension to link type=0A = OR =0A 2) Junk value. =0A=0ANow case (2) should not be allowed= to sneak through to allow for case (1).=0ABetter if the range of UNKNOWN i= s defined.=0A=0A-Vivek=0A=0A=0AOn Fri, 21 Jan 2005 Vishwas Manral wrote := =0A>Thanks a lot Acee.=0A>=0A>As this is more like a bug fix, would the cat= egory be Standard Track or=0A>Informational?=0A>=0A>Thanks again,=0A>Vishwa= s=0A>-----Original Message-----=0A> From: Mailing List [mailto:OSPF@PEACH.E= ASE.LSOFT.COM] On Behalf Of Acee=0A>Lindem=0A>Sent: Thursday, January 20, 2= 005 7:53 AM=0A>To: OSPF@PEACH.EASE.LSOFT.COM=0A>Subject: Re: draft-manral-o= spf-router-lsa-unknown-type-02=0A>=0A>Vishwas Manral wrote:=0A>=0A> > Hi fo= lks,=0A> >=0A> >=0A> >=0A> > I would want to progress the following draft t= o completion: -=0A> >=0A> >=0A>http://www.ietf.org/internet-drafts/draft-ma= nral-ospf-router-lsa-unknown=0A>-type-02.txt=0A> >=0A> >=0A> >=0A> > Would = we want to leave it as it is, make it an individual submission=0A> > to IES= G, or first make a WG draft and submit then it to IESG?=0A> >=0A>Any opinio= ns on this draft?=0A>=0A>Speaking as a WG member I'd support it. We'll sche= dule 5-10 minutes in=0A>Minneapolis to=0A>discuss.=0A>=0A>Thanks,=0A>Acee= =0A> >=0A> > Thanks,=0A> > Vishwas=0A> >=0A --Next_1106388064---0-203.199.83.245-27168 Content-type: text/html; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

=0AVishwas,
=0A
=0ADraft doesnt say anything about the case "= All links have unknown link type"  in the Router Lsa. Such an inf= ormation should be left for opaque LSAs.
=0A
=0AFurther -
=0AUnkno= wn : 1) Extension to link type
=0A          OR =
=0A          2) Junk value.
=0A
=0ANow = case (2) should not be allowed to sneak through to allow for case (1).
= =0ABetter if the range of UNKNOWN is defined.
=0A
=0A-Vivek
=0A=0A
=0AOn Fri, 21 Jan 2005 Vishwas Manral wrote :
=0A>Thanks a lo= t Acee.
=0A>
=0A>As this is more like a bug fix, would the cate= gory be Standard Track or
=0A>Informational?
=0A>
=0A>Tha= nks again,
=0A>Vishwas
=0A>-----Original Message-----
=0A>= ; From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Acee=0A>Lindem
=0A>Sent: Thursday, January 20, 2005 7:53 AM
=0A&g= t;To: OSPF@PEACH.EASE.LSOFT.COM
=0A>Subject: Re: draft-manral-ospf-ro= uter-lsa-unknown-type-02
=0A>
=0A>Vishwas Manral wrote:
=0A&= gt;
=0A> > Hi folks,
=0A> >
=0A> >
=0A> &g= t;
=0A> > I would want to progress the following draft to completi= on: -
=0A> >
=0A> >
=0A>http://www.ietf.org/interne= t-drafts/draft-manral-ospf-router-lsa-unknown
=0A>-type-02.txt
=0A= > >
=0A> >
=0A> >
=0A> > Would we want to = leave it as it is, make it an individual submission
=0A> > to IESG= , or first make a WG draft and submit then it to IESG?
=0A> >
= =0A>Any opinions on this draft?
=0A>
=0A>Speaking as a WG me= mber I'd support it. We'll schedule 5-10 minutes in
=0A>Minneapolis t= o
=0A>discuss.
=0A>
=0A>Thanks,
=0A>Acee
=0A>= >
=0A> > Thanks,
=0A> > Vishwas
=0A> >
= =0A=0A

=0A

=0A=0A --Next_1106388064---0-203.199.83.245-27168-- From owner-ospf@PEACH.EASE.LSOFT.COM Sat Jan 22 05:39:31 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25058 for ; Sat, 22 Jan 2005 05:39:31 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00F55C22@cherry.ease.lsoft.com>; Sat, 22 Jan 2005 5:39:32 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 54568146 for OSPF@PEACH.EASE.LSOFT.COM; Sat, 22 Jan 2005 05:39:30 -0500 Received: from 63.197.255.158 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sat, 22 Jan 2005 05:39:30 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: draft-manral-ospf-router-lsa-unknown-type-02 thread-index: AcT/xMSVSDvx1Rh7RVKnDUoPXRI1tgAdHsfwAA1nB+A= Message-ID: Date: Sat, 22 Jan 2005 02:47:51 -0800 Reply-To: Mailing List Sender: Mailing List From: Vishwas Manral Subject: Re: draft-manral-ospf-router-lsa-unknown-type-02 To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Hi Mani, You have a good point there. One of the reasons to define the behavior is to allow new types to be propagated.=20 However the main motivation is that the RFC does not specify the exact way of treating unknown link types which in some cases can result in routing loops. Acee, I will prepare the slides and pass them onto you. Vivek, Thanks for reviewing the draft. > Draft doesnt say anything about the case "All links have unknown link > type" in the Router Lsa. Such an information should be left for opaque > LSAs. I may be off target but we are not defining extensions; we are clarifying the behavior in case unknown link type in Router LSA is found during SPF calculation. > Further - > Unknown : 1) Extension to link type > OR=20 > 2) Junk value.=20 > Now case (2) should not be allowed to sneak through to allow for case (1). > Better if the range of UNKNOWN is defined. I do not see a reason that is required at all. Any unknown type is ignored, if there is an errored type("Junk value") all the routers will ignore the link so it does not create any issues. Thanks, Vishwas -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Manikantan Srinivasan Sent: Saturday, January 22, 2005 9:54 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: draft-manral-ospf-router-lsa-unknown-type-02 Hello Acee, Vishwas I understand the ability to add new link types to the router LSA is to enable new implementations/applications to propagate new link types and their associated additional link information. This information will be used (currently) by few implementation and others need to ignore. Hence the clarification / addition to the standard. Do we need to add new link types to the router LSA? Can't we use the Opaque LSAs to pass the additional/new information?=20 Best regards mani =20 # -----Original Message----- # From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On=20 # Behalf Of Acee Lindem # Sent: Friday, January 21, 2005 7:50 PM # To: OSPF@PEACH.EASE.LSOFT.COM # Subject: Re: draft-manral-ospf-router-lsa-unknown-type-02 #=20 # Vishwas Manral wrote: #=20 # >Thanks a lot Acee. # > # >As this is more like a bug fix, would the category be=20 # Standard Track or=20 # >Informational? # > =20 # > # I guess standards track would be better and than I'd include=20 # the change in the OSPFv3 update. # Since we are going from undefined to defined behavior we have=20 # to be careful as to how the draft is ultimately worded. #=20 # Could you prepare a couple slides for the Minneapolis IETF?=20 # If you are not going to be there, I could certainly present it. #=20 # >Thanks again, # >Vishwas # >-----Original Message----- # >From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On=20 # Behalf Of Acee=20 # >Lindem # >Sent: Thursday, January 20, 2005 7:53 AM # >To: OSPF@PEACH.EASE.LSOFT.COM # >Subject: Re: draft-manral-ospf-router-lsa-unknown-type-02 # > # >Vishwas Manral wrote: # > # > =20 # > # >>Hi folks, # >> # >>=20 # >> # >>I would want to progress the following draft to completion: - # >> # >> # >> =20 # >> # >http://www.ietf.org/internet-drafts/draft-manral-ospf-router- # lsa-unknow # >n # >-type-02.txt # > =20 # > # >>=20 # >> # >>Would we want to leave it as it is, make it an individual=20 # submission=20 # >>to IESG, or first make a WG draft and submit then it to IESG? # >> # >> =20 # >> # >Any opinions on this draft? # > # >Speaking as a WG member I'd support it. We'll schedule 5-10=20 # minutes in=20 # >Minneapolis to discuss. # > # >Thanks, # >Acee # > =20 # > # >>Thanks, # >>Vishwas # >> # >> =20 # >> # > # > =20 # > #=20 From owner-ospf@PEACH.EASE.LSOFT.COM Sat Jan 22 06:27:22 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27189 for ; Sat, 22 Jan 2005 06:27:22 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00F55D45@cherry.ease.lsoft.com>; Sat, 22 Jan 2005 6:27:22 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 54595023 for OSPF@PEACH.EASE.LSOFT.COM; Sat, 22 Jan 2005 06:27:20 -0500 Received: from 61.144.161.53 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sat, 22 Jan 2005 06:27:19 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IAP003S0UIDKS@szxga01-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Sat, 22 Jan 2005 19:27:50 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IAP00N6HUID2X@szxga01-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Sat, 22 Jan 2005 19:27:49 +0800 (CST) Received: from dell60 ([10.18.4.200]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IAP0058BUNOH8@szxml01-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Sat, 22 Jan 2005 19:31:01 +0800 (CST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.4024 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Message-ID: <000001c50076$40caf170$c804120a@in.huawei.com> Date: Sat, 22 Jan 2005 17:03:53 +0530 Reply-To: Mailing List Sender: Mailing List From: sujay Subject: Re: draft-manral-ospf-router-lsa-unknown-type-02 To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7BIT Vishwas; As per your draft; Let us assume; In case if the LinkStateDatabse copy of the router LSA is corrupted during SPF(or run-time !); And the SPF encounters an unknown link lsa type , it proceeds with the next link.Probably as the lsa is corrupted this could lead to recursive processing in the SPF. Hence maybe the draft should mention specifically to stop processing furher if the link count(in the header) is exhausted ! Regds, Sujay -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Vishwas Manral Sent: Saturday, January 22, 2005 4:18 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: draft-manral-ospf-router-lsa-unknown-type-02 Hi Mani, You have a good point there. One of the reasons to define the behavior is to allow new types to be propagated. However the main motivation is that the RFC does not specify the exact way of treating unknown link types which in some cases can result in routing loops. Acee, I will prepare the slides and pass them onto you. Vivek, Thanks for reviewing the draft. > Draft doesnt say anything about the case "All links have unknown link > type" in the Router Lsa. Such an information should be left for opaque > LSAs. I may be off target but we are not defining extensions; we are clarifying the behavior in case unknown link type in Router LSA is found during SPF calculation. > Further - > Unknown : 1) Extension to link type > OR > 2) Junk value. > Now case (2) should not be allowed to sneak through to allow for case (1). > Better if the range of UNKNOWN is defined. I do not see a reason that is required at all. Any unknown type is ignored, if there is an errored type("Junk value") all the routers will ignore the link so it does not create any issues. Thanks, Vishwas -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Manikantan Srinivasan Sent: Saturday, January 22, 2005 9:54 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: draft-manral-ospf-router-lsa-unknown-type-02 Hello Acee, Vishwas I understand the ability to add new link types to the router LSA is to enable new implementations/applications to propagate new link types and their associated additional link information. This information will be used (currently) by few implementation and others need to ignore. Hence the clarification / addition to the standard. Do we need to add new link types to the router LSA? Can't we use the Opaque LSAs to pass the additional/new information? Best regards mani # -----Original Message----- # From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On # Behalf Of Acee Lindem # Sent: Friday, January 21, 2005 7:50 PM # To: OSPF@PEACH.EASE.LSOFT.COM # Subject: Re: draft-manral-ospf-router-lsa-unknown-type-02 # # Vishwas Manral wrote: # # >Thanks a lot Acee. # > # >As this is more like a bug fix, would the category be # Standard Track or # >Informational? # > # > # I guess standards track would be better and than I'd include # the change in the OSPFv3 update. # Since we are going from undefined to defined behavior we have # to be careful as to how the draft is ultimately worded. # # Could you prepare a couple slides for the Minneapolis IETF? # If you are not going to be there, I could certainly present it. # # >Thanks again, # >Vishwas # >-----Original Message----- # >From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On # Behalf Of Acee # >Lindem # >Sent: Thursday, January 20, 2005 7:53 AM # >To: OSPF@PEACH.EASE.LSOFT.COM # >Subject: Re: draft-manral-ospf-router-lsa-unknown-type-02 # > # >Vishwas Manral wrote: # > # > # > # >>Hi folks, # >> # >> # >> # >>I would want to progress the following draft to completion: - # >> # >> # >> # >> # >http://www.ietf.org/internet-drafts/draft-manral-ospf-router- # lsa-unknow # >n # >-type-02.txt # > # > # >> # >> # >>Would we want to leave it as it is, make it an individual # submission # >>to IESG, or first make a WG draft and submit then it to IESG? # >> # >> # >> # >Any opinions on this draft? # > # >Speaking as a WG member I'd support it. We'll schedule 5-10 # minutes in # >Minneapolis to discuss. # > # >Thanks, # >Acee # > # > # >>Thanks, # >>Vishwas # >> # >> # >> # > # > # > # From owner-ospf@PEACH.EASE.LSOFT.COM Sat Jan 22 23:59:25 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03997 for ; Sat, 22 Jan 2005 23:59:23 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.00F56E70@cherry.ease.lsoft.com>; Sat, 22 Jan 2005 23:59:16 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 54677417 for OSPF@PEACH.EASE.LSOFT.COM; Sat, 22 Jan 2005 23:59:08 -0500 Received: from 204.176.140.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sat, 22 Jan 2005 23:59:08 -0500 Received: from manikantan (dsl-TN-121.240.247.61.touchtelindia.net [61.247.240.121] (may be forged)) (authenticated bits=0) by mail2.webindia.com (8.13.1/8.13.1) with ESMTP id j0N52MMX013516 for ; Sat, 22 Jan 2005 21:02:32 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 thread-index: AcT/xMSVSDvx1Rh7RVKnDUoPXRI1tgAdHsfwAA1nB+AAJPOKEA== X-IBIS-MailScanner-Information: Please contact the ISP for more information X-IBIS-MailScanner: Found to be clean X-MailScanner-From: manis@net-o2.com Message-ID: <200501230502.j0N52MMX013516@mail2.webindia.com> Date: Sun, 23 Jan 2005 10:28:57 +0530 Reply-To: Mailing List Sender: Mailing List From: Manikantan Srinivasan Organization: Net-O2 Technologies Subject: Re: draft-manral-ospf-router-lsa-unknown-type-02 To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit Dear Vishwas Good day to you. Thanks for your clarification. # -----Original Message----- # From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On # Behalf Of Vishwas Manral # Sent: Saturday, January 22, 2005 4:18 PM # To: OSPF@PEACH.EASE.LSOFT.COM # Subject: Re: draft-manral-ospf-router-lsa-unknown-type-02 # # Hi Mani, # # You have a good point there. One of the reasons to define the # behavior is to allow new types to be propagated. # # However the main motivation is that the RFC does not specify # the exact way of treating unknown link types which in some # cases can result in routing loops. # I welcome and accept your suggestion to update the standard - to specify the exact way of treating unknown (also can be called as Invalid) link types. This will make the standard consistent as well, for example in the LS Update processing, the standard says ignore the LSA which has unknown LS type.(Ref Sec 13 Bullet 2 page 143 - RFC 2328) A small typo in the current draft - Section 3 "Section A.4.3 [OSPFv3] described the various" needs to be changed as "Section A.4.3 [OSPFv3] describes the various". When I read your draft again, I could not visualize a scenario that results in the formation of loops, when a router ignores a received Router LSA with unknown/invalid LSA. Can you add an example as part of your slides please? It will be helpful, if it can be added to the draft too. Suppose we have a situation as mentioned by Sujay, "the LinkStateDatabse copy of the router LSA is corrupted during SPF(or run-time !)" I think, the standard's suggestion to ignore the wrong Link type information will result in a "Microloop" Let us consider the following sample network. +--+ 1 +--+ |A |---------|B | +--+ +--+ | | 5| |1 | | +--+ 10 +--+ |E |---------|C | +--+ +--+ A can reach E directly with metric 5. B can reach E via A with metric 6 Suppose the link type describing A-E link gets corrupted, and is ignored during SPF calculation at A, A will determine the path to reach E is via B and C with a metric of 12. (Since the LSA gets corrupted, this corrupted LSA is visible only at A.) A sends packets destined for E to B and B sends it to A, resulting in a loop. This loop will exist until the next refresh of Router LSA, where Router A has a chance to update its router LSA with correct information. If you feel, the above discussion is valid and is an (a security ?) issue, you can add it to section 5 of your draft. Feel free to ignore if this is invalid. Best regards Mani P.S. Invalid is applicable when the link type gets corrupted. From owner-ospf@PEACH.EASE.LSOFT.COM Sun Jan 23 05:27:41 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02714 for ; Sun, 23 Jan 2005 05:27:40 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.00F575CF@cherry.ease.lsoft.com>; 23 Jan 2005 5:27:40 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 54694258 for OSPF@PEACH.EASE.LSOFT.COM; Sun, 23 Jan 2005 05:27:39 -0500 Received: from 63.197.255.158 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sun, 23 Jan 2005 05:27:39 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: draft-manral-ospf-router-lsa-unknown-type-02 thread-index: AcT/xMSVSDvx1Rh7RVKnDUoPXRI1tgAdHsfwAA1nB+AAJPOKEAAMlkLA Message-ID: Date: Sun, 23 Jan 2005 02:36:00 -0800 Reply-To: Mailing List Sender: Mailing List From: Vishwas Manral Subject: Re: draft-manral-ospf-router-lsa-unknown-type-02 To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Hi Mani, Thanks for the suggestions. I will incorporate them. However corruption of LS-Type could occur to a valid value, an error would still occur and will stay till a new version of the LSA is received or if the LSA is refreshed.=20 One way to get over it is to have periodic checksum verification (I think some implementations do this, but I am unable to find it in any document). Sujay, From 2328 "The checksum of an LSA is verified in two cases: a) when it is received in a Link State Update Packet and b) at times during the aging of the link state database" I agree an implementation should take care that processing loops during SPF calculation should not occur. However I think that is implementation specific about how it should be implemented. Do let me know if I am wrong? Thanks, Vishwas -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Manikantan Srinivasan Sent: Sunday, January 23, 2005 10:29 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: draft-manral-ospf-router-lsa-unknown-type-02 Dear Vishwas Good day to you. Thanks for your clarification.=20 # -----Original Message----- # From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On=20 # Behalf Of Vishwas Manral # Sent: Saturday, January 22, 2005 4:18 PM # To: OSPF@PEACH.EASE.LSOFT.COM # Subject: Re: draft-manral-ospf-router-lsa-unknown-type-02 #=20 # Hi Mani, #=20 # You have a good point there. One of the reasons to define the=20 # behavior is to allow new types to be propagated.=20 #=20 # However the main motivation is that the RFC does not specify=20 # the exact way of treating unknown link types which in some=20 # cases can result in routing loops. #=20 I welcome and accept your suggestion to update the standard - to specify the exact way of treating unknown (also can be called as Invalid) link types. This will make the standard consistent as well, for example in the LS Update processing, the standard says ignore the LSA which has unknown LS type.(Ref Sec 13 Bullet 2 page 143 - RFC 2328) A small typo in the current draft - Section 3 "Section A.4.3 [OSPFv3] described the various" needs to be changed as "Section A.4.3 [OSPFv3] describes the various".=20 When I read your draft again, I could not visualize a scenario that results in the formation of loops, when a router ignores a received Router LSA with unknown/invalid LSA. Can you add an example as part of your slides please? It will be helpful, if it can be added to the draft too. Suppose we have a situation as mentioned by Sujay, "the LinkStateDatabse copy of the router LSA is corrupted during SPF(or run-time !)" I think, the standard's suggestion to ignore the wrong Link type information will result in a "Microloop" Let us consider the following sample network. +--+ 1 +--+ |A |---------|B | +--+ +--+ | | 5| |1 | | +--+ 10 +--+ |E |---------|C | +--+ +--+ A can reach E directly with metric 5. B can reach E via A with metric 6 Suppose the link type describing A-E link gets corrupted, and is ignored during SPF calculation at A, A will determine the path to reach E is via B and C with a metric of 12. (Since the LSA gets corrupted, this corrupted LSA is visible only at A.) A sends packets destined for E to B and B sends it to A, resulting in a loop. This loop will exist until the next refresh of Router LSA, where Router A has a chance to update its router LSA with correct information. If you feel, the above discussion is valid and is an (a security ?) issue, you can add it to section 5 of your draft. Feel free to ignore if this is invalid. Best regards Mani P.S. Invalid is applicable when the link type gets corrupted. From owner-ospf@PEACH.EASE.LSOFT.COM Mon Jan 24 00:56:58 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23627 for ; Mon, 24 Jan 2005 00:56:56 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00F58509@cherry.ease.lsoft.com>; Mon, 24 Jan 2005 0:56:53 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 54797554 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 24 Jan 2005 00:56:48 -0500 Received: from 61.144.161.55 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 24 Jan 2005 00:56:47 -0500 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IAT00JK74CVMW@szxga03-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Mon, 24 Jan 2005 13:53:19 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IAT00H8V4CVMR@szxga03-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Mon, 24 Jan 2005 13:53:19 +0800 (CST) Received: from dell60 ([10.18.4.200]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IAT008SF4F0I6@szxml02-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Mon, 24 Jan 2005 13:54:37 +0800 (CST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.4024 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Message-ID: <000001c501d9$f44571d0$c804120a@in.huawei.com> Date: Mon, 24 Jan 2005 11:30:05 +0530 Reply-To: Mailing List Sender: Mailing List From: sujay Subject: Re: draft-manral-ospf-router-lsa-unknown-type-02 To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7BIT Hi Vishwas, Thank you very for your response. The point I was driving to is this; Without following the new draft 'any' Implementation would drop the router lsa. In case of both corrupted lsa else invalid lsa type. After following the draft, it could lead to processing loops; Should or should not the implementation be made aware of this issue ? Regds, Sujay -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Vishwas Manral Sent: Sunday, January 23, 2005 4:06 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: draft-manral-ospf-router-lsa-unknown-type-02 Hi Mani, Thanks for the suggestions. I will incorporate them. However corruption of LS-Type could occur to a valid value, an error would still occur and will stay till a new version of the LSA is received or if the LSA is refreshed. One way to get over it is to have periodic checksum verification (I think some implementations do this, but I am unable to find it in any document). Sujay, From 2328 "The checksum of an LSA is verified in two cases: a) when it is received in a Link State Update Packet and b) at times during the aging of the link state database" I agree an implementation should take care that processing loops during SPF calculation should not occur. However I think that is implementation specific about how it should be implemented. Do let me know if I am wrong? Thanks, Vishwas -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Manikantan Srinivasan Sent: Sunday, January 23, 2005 10:29 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: draft-manral-ospf-router-lsa-unknown-type-02 Dear Vishwas Good day to you. Thanks for your clarification. # -----Original Message----- # From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On # Behalf Of Vishwas Manral # Sent: Saturday, January 22, 2005 4:18 PM # To: OSPF@PEACH.EASE.LSOFT.COM # Subject: Re: draft-manral-ospf-router-lsa-unknown-type-02 # # Hi Mani, # # You have a good point there. One of the reasons to define the # behavior is to allow new types to be propagated. # # However the main motivation is that the RFC does not specify # the exact way of treating unknown link types which in some # cases can result in routing loops. # I welcome and accept your suggestion to update the standard - to specify the exact way of treating unknown (also can be called as Invalid) link types. This will make the standard consistent as well, for example in the LS Update processing, the standard says ignore the LSA which has unknown LS type.(Ref Sec 13 Bullet 2 page 143 - RFC 2328) A small typo in the current draft - Section 3 "Section A.4.3 [OSPFv3] described the various" needs to be changed as "Section A.4.3 [OSPFv3] describes the various". When I read your draft again, I could not visualize a scenario that results in the formation of loops, when a router ignores a received Router LSA with unknown/invalid LSA. Can you add an example as part of your slides please? It will be helpful, if it can be added to the draft too. Suppose we have a situation as mentioned by Sujay, "the LinkStateDatabse copy of the router LSA is corrupted during SPF(or run-time !)" I think, the standard's suggestion to ignore the wrong Link type information will result in a "Microloop" Let us consider the following sample network. +--+ 1 +--+ |A |---------|B | +--+ +--+ | | 5| |1 | | +--+ 10 +--+ |E |---------|C | +--+ +--+ A can reach E directly with metric 5. B can reach E via A with metric 6 Suppose the link type describing A-E link gets corrupted, and is ignored during SPF calculation at A, A will determine the path to reach E is via B and C with a metric of 12. (Since the LSA gets corrupted, this corrupted LSA is visible only at A.) A sends packets destined for E to B and B sends it to A, resulting in a loop. This loop will exist until the next refresh of Router LSA, where Router A has a chance to update its router LSA with correct information. If you feel, the above discussion is valid and is an (a security ?) issue, you can add it to section 5 of your draft. Feel free to ignore if this is invalid. Best regards Mani P.S. Invalid is applicable when the link type gets corrupted. From owner-ospf@PEACH.EASE.LSOFT.COM Mon Jan 24 23:34:12 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09304 for ; Mon, 24 Jan 2005 23:34:11 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.00F5A19B@cherry.ease.lsoft.com>; Mon, 24 Jan 2005 23:34:13 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 54948851 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 24 Jan 2005 23:34:10 -0500 Received: from 205.158.62.67 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 24 Jan 2005 23:24:10 -0500 Received: from wfilter.us4.outblaze.com (wfilter.us4.outblaze.com [205.158.62.180]) by webmail-outgoing.us4.outblaze.com (Postfix) with QMQP id 6385A18001AC for ; Tue, 25 Jan 2005 04:24:10 +0000 (GMT) X-OB-Received: from unknown (205.158.62.81) by wfilter.us4.outblaze.com; 25 Jan 2005 04:23:58 -0000 Received: by ws1-2.us4.outblaze.com (Postfix, from userid 1001) id 3DCE91F50B1; Tue, 25 Jan 2005 04:23:58 +0000 (GMT) Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Received: from [203.197.138.199] by ws1-2.us4.outblaze.com with http for chrisjrc@email.com; Mon, 24 Jan 2005 23:23:58 -0500 X-Originating-Ip: 203.197.138.199 X-Originating-Server: ws1-2.us4.outblaze.com Message-ID: <20050125042358.3DCE91F50B1@ws1-2.us4.outblaze.com> Date: Mon, 24 Jan 2005 23:23:58 -0500 Reply-To: Mailing List Sender: Mailing List From: Christopher Jr Subject: Unknown LSA U-bit clarification To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Hi, I have the following doubt regarding Section A.4.2.1 (LS Type) RFC 2740). The RFC says=20 The U bit indicates how the LSA should be handled by a router which does not recognize the LSA's function code. Its values are: U-bit LSA Handling ------------------------------------------------------------- 0 Treat the LSA as if it had link-local flooding scope 1 Store and flood the LSA, as if type understood Does it mean, when the U-bit is clear, the LSA should not be stored. What does "Store and flood the LSA" exactly mean ? What is the difference between the following bit settings ? U S2 S1 --------- 0 0 0 1 0 0 Thanks, Christopher. --=20 ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm From owner-ospf@PEACH.EASE.LSOFT.COM Mon Jan 24 23:37:25 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09509 for ; Mon, 24 Jan 2005 23:37:24 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.00F5A063@cherry.ease.lsoft.com>; Mon, 24 Jan 2005 23:37:21 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 54950604 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 24 Jan 2005 23:37:19 -0500 Received: from 63.197.255.158 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 24 Jan 2005 23:37:19 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: Unknown LSA U-bit clarification thread-index: AcUCmHsFjhUsVdDIRP6V1eyshoNJugAAB2+A Message-ID: Date: Mon, 24 Jan 2005 20:45:45 -0800 Reply-To: Mailing List Sender: Mailing List From: Vishwas Manral Subject: Re: Unknown LSA U-bit clarification To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Hi Chris, "Store and flood" <=3D> "Treat". Thanks, Vishwas -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Christopher Jr Sent: Tuesday, January 25, 2005 9:54 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Unknown LSA U-bit clarification Hi, I have the following doubt regarding Section A.4.2.1 (LS Type) RFC 2740). The RFC says=20 The U bit indicates how the LSA should be handled by a router which does not recognize the LSA's function code. Its values are: U-bit LSA Handling ------------------------------------------------------------- 0 Treat the LSA as if it had link-local flooding scope 1 Store and flood the LSA, as if type understood Does it mean, when the U-bit is clear, the LSA should not be stored. What does "Store and flood the LSA" exactly mean ? What is the difference between the following bit settings ? U S2 S1 --------- 0 0 0 1 0 0 Thanks, Christopher. --=20 ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jan 25 00:08:07 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11672 for ; Tue, 25 Jan 2005 00:08:07 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.00F5A14D@cherry.ease.lsoft.com>; Tue, 25 Jan 2005 0:08:09 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 54954103 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 25 Jan 2005 00:08:05 -0500 Received: from 64.102.122.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 25 Jan 2005 00:08:00 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 25 Jan 2005 00:08:00 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j0P57woA002412 for ; Tue, 25 Jan 2005 00:07:59 -0500 (EST) Received: from [10.21.147.233] (sjc-vpn7-1001.cisco.com [10.21.147.233]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BEU89267; Mon, 24 Jan 2005 21:07:58 -0800 (PST) User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <20050125042358.3DCE91F50B1@ws1-2.us4.outblaze.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <41F5D42E.1010601@cisco.com> Date: Tue, 25 Jan 2005 00:07:58 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Unknown LSA U-bit clarification To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <20050125042358.3DCE91F50B1@ws1-2.us4.outblaze.com> Precedence: list Content-Transfer-Encoding: 7bit Christopher Jr wrote: >Hi, > >I have the following doubt regarding Section A.4.2.1 (LS Type) RFC 2740). >The RFC says > > The U bit indicates how the LSA should be handled by a router which > does not recognize the LSA's function code. Its values are: > > U-bit LSA Handling > ------------------------------------------------------------- > 0 Treat the LSA as if it had link-local flooding scope > 1 Store and flood the LSA, as if type understood > >Does it mean, when the U-bit is clear, the LSA should not be stored. >What does "Store and flood the LSA" exactly mean ? > > Hi Chris, It means that the LSA will be stored in the database associated with the link (similiar to a link-LSA) and not flooded beyond the local link. >What is the difference between the following bit settings ? > > U S2 S1 > --------- > 0 0 0 > 1 0 0 > > There is no difference in the handling of the LSA. Thanks, Acee >Christopher. > > From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jan 25 00:42:28 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13486 for ; Tue, 25 Jan 2005 00:42:24 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.00F5A260@cherry.ease.lsoft.com>; Tue, 25 Jan 2005 0:42:25 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 54955894 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 25 Jan 2005 00:42:23 -0500 Received: from 205.158.62.67 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 25 Jan 2005 00:42:23 -0500 Received: from wfilter.us4.outblaze.com (wfilter.us4.outblaze.com [205.158.62.180]) by webmail-outgoing.us4.outblaze.com (Postfix) with QMQP id D396518001BF for ; Tue, 25 Jan 2005 05:42:23 +0000 (GMT) X-OB-Received: from unknown (205.158.62.51) by wfilter.us4.outblaze.com; 25 Jan 2005 05:42:23 -0000 Received: by ws1-5.us4.outblaze.com (Postfix, from userid 1001) id 4EC2F6EEF6; Tue, 25 Jan 2005 05:42:23 +0000 (GMT) Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Received: from [203.197.138.199] by ws1-5.us4.outblaze.com with http for chrisjrc@email.com; Tue, 25 Jan 2005 00:42:23 -0500 X-Originating-Ip: 203.197.138.199 X-Originating-Server: ws1-5.us4.outblaze.com Message-ID: <20050125054223.4EC2F6EEF6@ws1-5.us4.outblaze.com> Date: Tue, 25 Jan 2005 00:42:23 -0500 Reply-To: Mailing List Sender: Mailing List From: Christopher Jr Subject: Re: Unknown LSA U-bit clarification To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Hi Vishwas/Acee Thanks for clarifying the doubt. Regards, Chris. ----- Original Message ----- From: "Acee Lindem" To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: Unknown LSA U-bit clarification Date: Tue, 25 Jan 2005 00:07:58 -0500 >=20 > Christopher Jr wrote: >=20 > > Hi, > > > > I have the following doubt regarding Section A.4.2.1 (LS Type) RFC 2740= ). > > The RFC says The U bit indicates how the LSA should be handled=20 > > by a router which > > does not recognize the LSA's function code. Its values are: > > > > U-bit LSA Handling > > ------------------------------------------------------------- > > 0 Treat the LSA as if it had link-local flooding scope > > 1 Store and flood the LSA, as if type understood > > > > Does it mean, when the U-bit is clear, the LSA should not be stored. > > What does "Store and flood the LSA" exactly mean ? > > > > > Hi Chris, > It means that the LSA will be stored in the database associated=20 > with the link (similiar to a link-LSA) and not flooded beyond the=20 > local link. >=20 >=20 > > What is the difference between the following bit settings ? > > > > U S2 S1 > > --------- > > 0 0 0 > > 1 0 0 > > > > > There is no difference in the handling of the LSA. >=20 > Thanks, > Acee >=20 > > Christopher. > > > > --=20 ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jan 25 19:01:36 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27430 for ; Tue, 25 Jan 2005 19:01:35 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.00F5C1F3@cherry.ease.lsoft.com>; Tue, 25 Jan 2005 19:01:36 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 55077728 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 25 Jan 2005 19:01:17 -0500 Received: from 207.217.121.248 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 25 Jan 2005 19:01:16 -0500 Received: from user-2ivfj37.dialup.mindspring.com ([165.247.204.103] helo=earthlink.net) by pop-a065d01.pas.sa.earthlink.net with esmtp (Exim 3.33 #1) id 1CtacV-0001iv-00 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 25 Jan 2005 16:01:16 -0800 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <41F6DEAF.EF0B2C68@earthlink.net> Date: Tue, 25 Jan 2005 16:05:03 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: draft-manral-ospf-router-lsa-unknown-type-02 To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Group, Sorry about my late reply. I have a bad cold. :-( If I was to agree that we should process/forward unknown LSA link types, I think the wording specified in the draft is abit ambiguous.. Router LSA link-types 1,2, 3, and 4 are defined in RFC2328. However, a router may imploy a superset of link-types say supporting additional link-types, say link-type 5 for wireless links.. Thus, shouldn't the "should now read" deal with RFC 2328 Router LSA link-types unknowns and router-id router LSA link-type unknowns with link-type 6 or more????? So, does the "Unknown Link Types are ignored" (last sentance in ""2. Changes for OSPFv2"") deal with the RFC2328 unknowns or router-id router unknowns? I assume it is the later.. NOW, ......... When we have a stub area.. FYI, the original reason for stub areas (Moy OSPF books) was to reduce the memory requirments.. 1) simple case first.. Doesn't it make sense that if ALL the link-types within a ROUTER LSA are RFC2328 unknown that the LSA just consumes memory and CPU cycles.. Thus, in my opinion these LSAs should not be present in the routers within a stub area. or that all the routers within the area match the router-id router LSA link-type unknown.. I have been considering whether this ADJ should even be up if the router ONLY originates Router LSAs with unknown link-types??? Is it acting basicly as a passive adj? We can't send data packets over the link, but we should be able to recieve data packets.. Thus, I think we have a 1-way data link. 2) This falls into a subcategory of #1. If some of the link-types are known within a Router LSA, the unknowns should be stripped from the Router LSA. This should reduce the flooding overhead and memory requirements. It does require a memory copy to reduce the size of the router LSA. The assumption here is that the unknown link-types should be stripped. However, should they been originated in the first place??? Should displays (implimentation dependent) identify routers that generate router LSAs with unknown link-types? Thus, their are at least, LSA origination, flooding, and SPF issues that need to be addressed for the two definitions of "unknowns" and stub/not stub areas. Mitchell Erblich From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jan 26 03:37:34 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01228 for ; Wed, 26 Jan 2005 03:37:33 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.00F5CD38@cherry.ease.lsoft.com>; Wed, 26 Jan 2005 3:37:33 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 55113355 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 26 Jan 2005 03:37:31 -0500 Received: from 203.199.83.245 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 26 Jan 2005 03:37:30 -0500 Received: (qmail 5309 invoked by uid 510); 26 Jan 2005 08:39:03 -0000 Received: from unknown (203.126.136.220) by rediffmail.com via HTTP; 26 jan 2005 08:39:03 -0000 MIME-Version: 1.0 Content-type: multipart/alternative; boundary="Next_1106728743---0-203.199.83.245-5302" Message-ID: <20050126083903.5308.qmail@mailweb33.rediffmail.com> Date: Wed, 26 Jan 2005 08:39:03 -0000 Reply-To: Mailing List Sender: Mailing List From: Vivek Dubey Subject: draft-manral-ospf-router-lsa-unknown-type-02 To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This is a multipart mime message --Next_1106728743---0-203.199.83.245-5302 Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Vishwas,=0A=0ASection 1.=0A----------=0AIncase the a Router LSA with an = unknown link type is received implementations treat the LSA differently. Wh= ile some implementations can ignore the link yet process the rest of the LS= A others can simply ignore the LSA. This leads to different databases in th= e routers and hence different routing tables. =0A=0A Why does it le= ad to different databases ? =0A Since links were (used/not used) in = different implementations, =0A so different routing tables can resul= t. =0A=0A Further what were the reasons that lead to decide in favor= of =0A ignoring unknown link type (and process rest of the router = =0A lsa) rather than ignoring the router lsa in calculation of =0A = routes.=0A=0A Were these reasons discussed in previous mail? = =0A =0A Morever this draft is allowing presence of information in=0A= OSPF LSAs ( i.e not Opaque LSAs), that is "unknown" to OSPF.=0A = If the purpose is to make space for extensions, better to =0A ex= tend LINK-TYPEs once extension is defined. =0A=0A Simpler approach w= ould have been to ignore the Router LSA in=0A the calculations and g= enerate a TRAP specifying the error.=0A=0A=0AThanks=0AVivek=0A=0A = =0A=0A =0A =0A =0A =0A =0A =0A=0A = =0A=0A=0A=0A --Next_1106728743---0-203.199.83.245-5302 Content-type: text/html; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

=0AHi Vishwas,
=0A
=0ASection 1.
=0A----------
=0AIncase the= a Router LSA with an unknown link type is received implementations treat t= he LSA differently. While some implementations can ignore the link yet proc= ess the rest of the LSA others can simply ignore the LSA. This leads to dif= ferent databases in the routers and hence different routing tables.  <= BR>=0A
=0A<vivek> Why does it lead to different databases ?
= =0A        Since links were (used/not used) in differen= t implementations,
=0A        so different routing = tables can result.
=0A
=0A        Further what w= ere the reasons that lead to decide in favor of
=0A     =   ignoring unknown link type (and process rest of the router  =0A        lsa) rather than ignoring the router lsa i= n calculation of
=0A        routes.
=0A
=0A&n= bsp;       Were these reasons discussed in previous mail? =0A
=0A        Morever this draft is allowing pre= sence of information in
=0A        OSPF LSAs ( i.e n= ot Opaque LSAs), that is "unknown" to OSPF.
=0A    &= nbsp;   If the purpose is to make space for extensions, better to
= =0A        extend LINK-TYPEs once extension is defined.=
=0A
=0A        Simpler approach would have been= to ignore the Router LSA in
=0A        the calculat= ions and generate a TRAP specifying the error.
=0A
=0A
=0AThanks=0AVivek
=0A
=0A       
=0A
=0A  &n= bsp;    
=0A 
=0A         =  
=0A       
=0A      &nb= sp;
=0A   
=0A
=0A       
=0A<= BR>=0A
=0A
=0A=0A

=0A

=0A=0A --Next_1106728743---0-203.199.83.245-5302-- From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jan 26 04:53:54 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06109 for ; Wed, 26 Jan 2005 04:53:52 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.00F5CB5E@cherry.ease.lsoft.com>; Wed, 26 Jan 2005 4:53:50 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 55116487 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 26 Jan 2005 04:53:41 -0500 Received: from 63.197.255.158 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 26 Jan 2005 04:53:41 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: draft-manral-ospf-router-lsa-unknown-type-02 thread-index: AcUDO5LRS/XKleGUT7OOSeh5wlyp2AAUkGGA Message-ID: Date: Wed, 26 Jan 2005 02:02:09 -0800 Reply-To: Mailing List Sender: Mailing List From: Vishwas Manral Subject: Re: draft-manral-ospf-router-lsa-unknown-type-02 To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Hi Mitchell, > So, does the "Unknown Link Types are ignored" (last > sentance in ""2. Changes for OSPFv2"") deal > with the RFC2328 unknowns or router-id router unknowns?=20 > I assume it is the later.. You are right and it's a good point. I will clarify this. Having complex cases as you said, however may complicate things. Thanks, Vishwas -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Erblichs Sent: Wednesday, January 26, 2005 5:35 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: draft-manral-ospf-router-lsa-unknown-type-02 Group, Sorry about my late reply. I have a bad cold. :-( If I was to agree that we should process/forward unknown LSA link types, I think the wording specified in the draft is abit ambiguous.. Router LSA link-types 1,2, 3, and 4 are defined in RFC2328. However, a router may imploy a superset of link-types say supporting additional link-types, say link-type 5 for wireless links..=20 Thus, shouldn't the "should now read" deal with RFC 2328 Router LSA link-types unknowns and router-id router LSA link-type unknowns with link-type 6 or more????? So, does the "Unknown Link Types are ignored" (last sentance in ""2. Changes for OSPFv2"") deal with the RFC2328 unknowns or router-id router unknowns?=20 I assume it is the later.. NOW, ......... When we have a stub area.. FYI, the original reason for stub areas (Moy OSPF books) was to reduce the memory requirments.. 1) simple case first.. Doesn't it make sense that if ALL the link-types within a ROUTER LSA are RFC2328 unknown that the LSA just consumes memory and CPU cycles.. Thus, in my opinion these LSAs should not be present in the routers within a stub area. or that all the routers within the area match the router-id router LSA link-type unknown.. I have been considering whether this ADJ should even be up if the router ONLY originates Router LSAs with unknown link-types??? Is it acting basicly as a passive adj? We can't send data packets over the link, but we should be able to recieve data packets.. Thus, I think we have a 1-way data link. =20 2) This falls into a subcategory of #1. If some of the link-types are known within a Router LSA, the unknowns should be stripped from the Router LSA. This should reduce the flooding overhead and memory requirements. It does require a memory copy to reduce the size of the router LSA.=20 The assumption here is that the unknown link-types should be stripped. However, should they been originated in the first place??? Should displays (implimentation dependent) identify routers that generate router LSAs with unknown link-types? Thus, their are at least, LSA origination, flooding,=09 and SPF issues that need to be addressed for the two definitions of "unknowns" and stub/not stub areas. Mitchell Erblich From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jan 26 04:58:26 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06343 for ; Wed, 26 Jan 2005 04:58:25 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.00F5CC2E@cherry.ease.lsoft.com>; Wed, 26 Jan 2005 4:58:21 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 55116955 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 26 Jan 2005 04:58:19 -0500 Received: from 63.197.255.158 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 26 Jan 2005 04:58:19 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: draft-manral-ospf-router-lsa-unknown-type-02 thread-index: AcUDg6WfI1juNG+ORAum16upU31kegACndVw Message-ID: Date: Wed, 26 Jan 2005 02:06:47 -0800 Reply-To: Mailing List Sender: Mailing List From: Vishwas Manral Subject: Re: draft-manral-ospf-router-lsa-unknown-type-02 To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Hi Vivek, > Why does it lead to different databases?=20 This leads to the databases being used by the SPF to be different in = different routers. I guess those are the exact words you are looking = for. I will clarify the text. > If the purpose is to make space for extensions, better to=20 > extend LINK-Types once extension is defined. Unless the text regarding how unknown LSA's are to be treated is = clarified such extensions cannot be added. Thanks, Vishwas ________________________________________ From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Vivek = Dubey Sent: Wednesday, January 26, 2005 2:09 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: draft-manral-ospf-router-lsa-unknown-type-02 Hi Vishwas, Section 1. ---------- Incase the a Router LSA with an unknown link type is received = implementations treat the LSA differently. While some implementations = can ignore the link yet process the rest of the LSA others can simply = ignore the LSA. This leads to different databases in the routers and = hence different routing tables.=A0=20 Why does it lead to different databases ?=20 =A0 =A0 =A0 =A0 Since links were (used/not used) in different = implementations,=20 =A0 =A0 =A0 =A0 so different routing tables can result.=20 =A0 =A0 =A0 =A0 Further what were the reasons that lead to decide in = favor of=20 =A0 =A0 =A0 =A0 ignoring unknown link type (and process rest of the = router=A0=20 =A0 =A0 =A0 =A0 lsa) rather than ignoring the router lsa in calculation = of=20 =A0 =A0 =A0 =A0 routes. =A0 =A0 =A0 =A0 Were these reasons discussed in previous mail?=20 =A0 =A0 =A0 =A0 Morever this draft is allowing presence of information = in =A0 =A0 =A0 =A0 OSPF LSAs ( i.e not Opaque LSAs), that is "unknown" to = OSPF. =A0 =A0 =A0 =A0 If the purpose is to make space for extensions, better = to=20 =A0 =A0 =A0 =A0 extend LINK-TYPEs once extension is defined.=20 =A0 =A0 =A0 =A0 Simpler approach would have been to ignore the Router = LSA in =A0 =A0 =A0 =A0 the calculations and generate a TRAP specifying the = error. Thanks Vivek =A0 =A0 =A0 =A0=20 =A0 =A0 =A0 =A0=20 =A0=20 =A0 =A0 =A0 =A0 =A0 =A0=20 =A0 =A0 =A0 =A0=20 =A0 =A0 =A0 =A0=20 =A0 =A0=20 =A0 =A0 =A0 =A0=20 From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jan 26 11:48:36 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15003 for ; Wed, 26 Jan 2005 11:48:35 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.00F5D20B@cherry.ease.lsoft.com>; Wed, 26 Jan 2005 11:48:29 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 55181509 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 26 Jan 2005 11:48:23 -0500 Received: from 64.102.122.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 26 Jan 2005 11:48:23 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 26 Jan 2005 11:48:23 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j0QGmKoA018586 for ; Wed, 26 Jan 2005 11:48:21 -0500 (EST) Received: from [128.107.176.234] (dhcp-128-107-176-234.cisco.com [128.107.176.234]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BEW00410; Wed, 26 Jan 2005 08:48:19 -0800 (PST) User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <41F6DEAF.EF0B2C68@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <41F7C9D3.8080105@cisco.com> Date: Wed, 26 Jan 2005 11:48:19 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: draft-manral-ospf-router-lsa-unknown-type-02 To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <41F6DEAF.EF0B2C68@earthlink.net> Precedence: list Content-Transfer-Encoding: 7bit Hi Mitchell, I don't think we want to do anything for stub areas. This draft was a result of RFC2328 not specifying what an should be done with unknown links types. We could have either reject the LSA or ignore the unknown types. The opinions on the list were overwhelmingly in favor of the latter. My opinion is that even with this draft we are going to be extremely conservative in our introduction of new link types. Furthermore, stub areas are protected from externally scoped advertisements. Note that router LSAs are area scoped and presumely each OSPF routing domain (and surely every area) is administratively controlled by a single party. Hence, the network administrator should have control over whether or not new links types are deployed in a stub area. Thanks, Acee Erblichs wrote: >Group, > > Sorry about my late reply. I have a bad cold. :-( > > If I was to agree that we should process/forward > unknown LSA link types, I think the wording specified > in the draft is abit ambiguous.. > > Router LSA link-types 1,2, 3, and 4 are defined > in RFC2328. However, a router may imploy a superset > of link-types say supporting additional link-types, > say link-type 5 for wireless links.. > > Thus, shouldn't the "should now read" deal with > RFC 2328 Router LSA link-types unknowns and router-id > router LSA link-type unknowns with link-type 6 or more????? > > So, does the "Unknown Link Types are ignored" (last > sentance in ""2. Changes for OSPFv2"") deal > with the RFC2328 unknowns or router-id router unknowns? > I assume it is the later.. > > NOW, ......... > > When we have a stub area.. FYI, the original reason > for stub areas (Moy OSPF books) was to reduce the > memory requirments.. > > 1) simple case first.. > > Doesn't it make sense that if ALL the link-types > within a ROUTER LSA are RFC2328 unknown that the LSA just > consumes memory and CPU cycles.. Thus, in my opinion > these LSAs should not be present in the routers within > a stub area. > > or that all the routers within the area match > the router-id router LSA link-type unknown.. > > I have been considering whether this ADJ should even > be up if the router ONLY originates Router LSAs > with unknown link-types??? Is it acting basicly > as a passive adj? We can't send data packets over > the link, but we should be able to recieve data > packets.. Thus, I think we have a 1-way data link. > > 2) This falls into a subcategory of #1. If some of the > link-types are known within a Router LSA, the unknowns > should be stripped from the Router LSA. This should > reduce the flooding overhead and memory requirements. > It does require a memory copy to reduce the size of the > router LSA. > > The assumption here is that the unknown link-types > should be stripped. However, should they been originated > in the first place??? Should displays (implimentation > dependent) identify routers that generate router LSAs > with unknown link-types? > > Thus, their are at least, LSA origination, flooding, > and SPF issues that need to be addressed for the > two definitions of "unknowns" and stub/not stub areas. > > Mitchell Erblich > > > From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jan 26 15:59:19 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16621 for ; Wed, 26 Jan 2005 15:59:15 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.00F5D6B7@cherry.ease.lsoft.com>; Wed, 26 Jan 2005 15:59:09 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 55207827 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 26 Jan 2005 15:59:08 -0500 Received: from 207.217.121.252 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 26 Jan 2005 15:59:07 -0500 Received: from user-2ivfjcm.dialup.mindspring.com ([165.247.205.150] helo=earthlink.net) by pop-a065d14.pas.sa.earthlink.net with esmtp (Exim 3.33 #1) id 1CtuFl-00024q-00 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 26 Jan 2005 12:59:06 -0800 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: <41F6DEAF.EF0B2C68@earthlink.net> <41F7C9D3.8080105@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <41F8057F.B381430C@earthlink.net> Date: Wed, 26 Jan 2005 13:02:55 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: draft-manral-ospf-router-lsa-unknown-type-02 To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Acee Lindem and et. al.. Yes and No.. I don't always agree with the general consensus. The stub area type is the easist to defend when it comes to the limited accepted link-types. However, it can and does apply to non stub areas, as presented below. Only 4 router LSA link-types are RFC2328 defined and should be used dealing with SPF calcs. If the undefines then deal with metric and monitoring, then I could understand the acceptance of unknowns, due to the fact that they can do no routing harm.. First, did any of your consensus see the two different Router LSA's with unknown link-types????? If we expound on on accepting, flooding, etc with your philosphy.. Then their is a RFC2328 section that hasn't been addressed. Section 13.2 specifies that when the body of a LSA has changed, it triggers a SPF calculation.... Did anybody see this??? By flooding the Router LSAs with unknown link-types any change with one unknown, the withdrawl of the unknown, etc.. will trigger SPF calculations.. The end result can't change, but must be run to be in Spec with the RFC. Do you really suggest running additional SPF calcs when the end result is the same?????? If they are stripped of unknowns this becomes a non-issue. Any change in the body dealing with unknown link-types is ignored, because only the stripped Router LSA is compared. Thus, IMO, a default area type dealing with router link-type (due to the fact thar Router LSAs are area scope), MUST ONLY accept the RFC2328 4 defined link-types. A router can literally dump huge amounts of unknown Router LSA contents which according to you must be flooded throughout the area without being able to do any verification on the contents. It's just opaque data. IFF new router link-types need to be supported, Shouldn't they be allowed as NEW capabilities??? With the new capabilities, they would need accompaning RFC information.. Thus, IMO this is the most conservative approach that could be taken. Mitchell Erblich -------------------------- Acee Lindem wrote: > > Hi Mitchell, > > I don't think we want to do anything for stub areas. This draft was > a result of RFC2328 not specifying what an should be done with > unknown links types. We could have either reject the LSA or > ignore the unknown types. The opinions on the list were overwhelmingly > in favor of the latter. My opinion is that even with this draft we are > going to be extremely conservative in our introduction of new link > types. > > Furthermore, stub areas are protected from externally scoped > advertisements. Note that router LSAs are area scoped and presumely > each OSPF routing domain (and surely every area) is administratively > controlled by a single party. Hence, the network administrator should have > control over whether or not new links types are deployed in a stub area. > > Thanks, > Acee > > Erblichs wrote: > > >Group, > > > > Sorry about my late reply. I have a bad cold. :-( > > > > If I was to agree that we should process/forward > > unknown LSA link types, I think the wording specified > > in the draft is abit ambiguous.. > > > > Router LSA link-types 1,2, 3, and 4 are defined > > in RFC2328. However, a router may imploy a superset > > of link-types say supporting additional link-types, > > say link-type 5 for wireless links.. > > > > Thus, shouldn't the "should now read" deal with > > RFC 2328 Router LSA link-types unknowns and router-id > > router LSA link-type unknowns with link-type 6 or more????? > > > > So, does the "Unknown Link Types are ignored" (last > > sentance in ""2. Changes for OSPFv2"") deal > > with the RFC2328 unknowns or router-id router unknowns? > > I assume it is the later.. > > > > NOW, ......... > > > > When we have a stub area.. FYI, the original reason > > for stub areas (Moy OSPF books) was to reduce the > > memory requirments.. > > > > 1) simple case first.. > > > > Doesn't it make sense that if ALL the link-types > > within a ROUTER LSA are RFC2328 unknown that the LSA just > > consumes memory and CPU cycles.. Thus, in my opinion > > these LSAs should not be present in the routers within > > a stub area. > > > > or that all the routers within the area match > > the router-id router LSA link-type unknown.. > > > > I have been considering whether this ADJ should even > > be up if the router ONLY originates Router LSAs > > with unknown link-types??? Is it acting basicly > > as a passive adj? We can't send data packets over > > the link, but we should be able to recieve data > > packets.. Thus, I think we have a 1-way data link. > > > > 2) This falls into a subcategory of #1. If some of the > > link-types are known within a Router LSA, the unknowns > > should be stripped from the Router LSA. This should > > reduce the flooding overhead and memory requirements. > > It does require a memory copy to reduce the size of the > > router LSA. > > > > The assumption here is that the unknown link-types > > should be stripped. However, should they been originated > > in the first place??? Should displays (implimentation > > dependent) identify routers that generate router LSAs > > with unknown link-types? > > > > Thus, their are at least, LSA origination, flooding, > > and SPF issues that need to be addressed for the > > two definitions of "unknowns" and stub/not stub areas. > > > > Mitchell Erblich > > > > > > From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jan 26 16:12:15 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19833 for ; Wed, 26 Jan 2005 16:12:13 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00F5D7AA@cherry.ease.lsoft.com>; Wed, 26 Jan 2005 16:12:14 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 55209967 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 26 Jan 2005 16:12:12 -0500 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 26 Jan 2005 16:12:12 -0500 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 8870133 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 26 Jan 2005 16:12:11 -0500 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 References: <41F6DEAF.EF0B2C68@earthlink.net> <41F7C9D3.8080105@cisco.com> <41F8057F.B381430C@earthlink.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <6.1.2.0.0.20050126161000.039c2c88@localhost> Date: Wed, 26 Jan 2005 16:11:04 -0500 Reply-To: Mailing List Sender: Mailing List From: "Joel M. Halpern" Subject: Re: draft-manral-ospf-router-lsa-unknown-type-02 To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <41F8057F.B381430C@earthlink.net> Precedence: list Remember that the implementation of the calculation is a local matter. In this case, the implementation can be "use the previous result" and it will still be consistent with the spec. Yours, Joel M. Halpern At 04:02 PM 1/26/2005, you wrote: > By flooding the Router LSAs with unknown link-types > any change with one unknown, the withdrawl of the > unknown, etc.. will trigger SPF calculations.. > > The end result can't change, but must be run to > be in Spec with the RFC. Do you really suggest running > additional SPF calcs when the end result is the > same?????? From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jan 26 17:29:02 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28666 for ; Wed, 26 Jan 2005 17:29:00 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.00F5DAC9@cherry.ease.lsoft.com>; Wed, 26 Jan 2005 17:29:01 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 55217605 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 26 Jan 2005 17:29:00 -0500 Received: from 64.102.122.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 26 Jan 2005 17:28:59 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 26 Jan 2005 17:37:48 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j0QMSqoA024012 for ; Wed, 26 Jan 2005 17:28:57 -0500 (EST) Received: from [10.32.14.227] ([10.32.14.227]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BEW33385; Wed, 26 Jan 2005 14:28:51 -0800 (PST) User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <41F6DEAF.EF0B2C68@earthlink.net> <41F7C9D3.8080105@cisco.com> <41F8057F.B381430C@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <41F819A2.4080509@cisco.com> Date: Wed, 26 Jan 2005 17:28:50 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: draft-manral-ospf-router-lsa-unknown-type-02 To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <41F8057F.B381430C@earthlink.net> Precedence: list Content-Transfer-Encoding: 7bit Mitchell, See inline. Erblichs wrote: >Acee Lindem and et. al.. > > Yes and No.. > I don't always agree with the general consensus. > > The stub area type is the easist to defend when > it comes to the limited accepted link-types. > However, it can and does apply to non stub areas, > as presented below. > > Only 4 router LSA link-types are RFC2328 defined and should be > used dealing with SPF calcs. If the undefines then > deal with metric and monitoring, then I could > understand the acceptance of unknowns, due to the > fact that they can do no routing harm.. > > First, did any of your consensus see the > two different Router LSA's with unknown link-types????? > > If we expound on on accepting, flooding, etc with > your philosphy.. Then their is a RFC2328 section > that hasn't been addressed. Section 13.2 specifies > that when the body of a LSA has changed, it triggers > a SPF calculation.... Did anybody see this??? > > By flooding the Router LSAs with unknown link-types > any change with one unknown, the withdrawl of the > unknown, etc.. will trigger SPF calculations.. > > The end result can't change, but must be run to > be in Spec with the RFC. Do you really suggest running > additional SPF calcs when the end result is the > same?????? If they are stripped of unknowns this > becomes a non-issue. Any change in the body dealing > with unknown link-types is ignored, because only > the stripped Router LSA is compared. > > For MTR (multi-topology routing) one should be smarter and actually determine what has changed before doing an SPF. Anyway, this is somewhat implementation specific. > Thus, IMO, a default area type dealing with > router link-type > (due to the fact thar Router LSAs are area scope), > MUST ONLY accept the RFC2328 4 defined link-types. > > Then you are advocating rejecting the LSA? > > A router can literally dump huge amounts of unknown > Router LSA contents which according to you must be > flooded throughout the area without being able to > do any verification on the contents. It's just opaque > data. > > > IFF new router link-types need to be supported, > Shouldn't they be allowed as NEW capabilities??? > With the new capabilities, they would need accompaning > RFC information.. > > We intend to be conservative in defining new link types and they will require standards action. > Thus, IMO this is the most conservative approach > that could be taken. > > > Mitchell Erblich > -------------------------- > > >Acee Lindem wrote: > > >>Hi Mitchell, >> >>I don't think we want to do anything for stub areas. This draft was >>a result of RFC2328 not specifying what an should be done with >>unknown links types. We could have either reject the LSA or >>ignore the unknown types. The opinions on the list were overwhelmingly >>in favor of the latter. My opinion is that even with this draft we are >>going to be extremely conservative in our introduction of new link >>types. >> >>Furthermore, stub areas are protected from externally scoped >>advertisements. Note that router LSAs are area scoped and presumely >>each OSPF routing domain (and surely every area) is administratively >>controlled by a single party. Hence, the network administrator should have >>control over whether or not new links types are deployed in a stub area. >> >>Thanks, >>Acee >> >>Erblichs wrote: >> >> >> >>>Group, >>> >>> Sorry about my late reply. I have a bad cold. :-( >>> >>> If I was to agree that we should process/forward >>> unknown LSA link types, I think the wording specified >>> in the draft is abit ambiguous.. >>> >>> Router LSA link-types 1,2, 3, and 4 are defined >>> in RFC2328. However, a router may imploy a superset >>> of link-types say supporting additional link-types, >>> say link-type 5 for wireless links.. >>> >>> Thus, shouldn't the "should now read" deal with >>> RFC 2328 Router LSA link-types unknowns and router-id >>> router LSA link-type unknowns with link-type 6 or more????? >>> >>> So, does the "Unknown Link Types are ignored" (last >>> sentance in ""2. Changes for OSPFv2"") deal >>> with the RFC2328 unknowns or router-id router unknowns? >>> I assume it is the later.. >>> >>> NOW, ......... >>> >>> When we have a stub area.. FYI, the original reason >>> for stub areas (Moy OSPF books) was to reduce the >>> memory requirments.. >>> >>> 1) simple case first.. >>> >>> Doesn't it make sense that if ALL the link-types >>> within a ROUTER LSA are RFC2328 unknown that the LSA just >>> consumes memory and CPU cycles.. Thus, in my opinion >>> these LSAs should not be present in the routers within >>> a stub area. >>> >>> or that all the routers within the area match >>> the router-id router LSA link-type unknown.. >>> >>> I have been considering whether this ADJ should even >>> be up if the router ONLY originates Router LSAs >>> with unknown link-types??? Is it acting basicly >>> as a passive adj? We can't send data packets over >>> the link, but we should be able to recieve data >>> packets.. Thus, I think we have a 1-way data link. >>> >>> 2) This falls into a subcategory of #1. If some of the >>> link-types are known within a Router LSA, the unknowns >>> should be stripped from the Router LSA. This should >>> reduce the flooding overhead and memory requirements. >>> It does require a memory copy to reduce the size of the >>> router LSA. >>> >>> The assumption here is that the unknown link-types >>> should be stripped. However, should they been originated >>> in the first place??? Should displays (implimentation >>> dependent) identify routers that generate router LSAs >>> with unknown link-types? >>> >>> Thus, their are at least, LSA origination, flooding, >>> and SPF issues that need to be addressed for the >>> two definitions of "unknowns" and stub/not stub areas. >>> >>> Mitchell Erblich >>> >>> >>> >>> >>> > > > From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jan 26 20:17:42 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11547 for ; Wed, 26 Jan 2005 20:17:40 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00F5DC7E@cherry.ease.lsoft.com>; Wed, 26 Jan 2005 20:17:32 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 55228314 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 26 Jan 2005 20:17:26 -0500 Received: from 207.217.121.251 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 26 Jan 2005 20:17:26 -0500 Received: from user-2ivfjcm.dialup.mindspring.com ([165.247.205.150] helo=earthlink.net) by pop-a065d10.pas.sa.earthlink.net with esmtp (Exim 3.33 #1) id 1CtyHg-00064Z-00 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 26 Jan 2005 17:17:21 -0800 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: <41F6DEAF.EF0B2C68@earthlink.net> <41F7C9D3.8080105@cisco.com> <41F8057F.B381430C@earthlink.net> <41F819A2.4080509@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <41F84202.72FBFE7B@earthlink.net> Date: Wed, 26 Jan 2005 17:21:06 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: draft-manral-ospf-router-lsa-unknown-type-02 To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Group, IMO, all router LSA link-types greater than 4 should be stripped upon reciept if they deal with determination of routing. >Then you are advocating rejecting the LSA? If ALL the link-types are undefined, yes then drop the entire router LSA after acking it. I don't have a compelling thought why we would really want to store this type of opaque data in our LSDB or consume bandwidth flooding it to MAYBE another router within our area that MIGHT understand it. And Murphys law says that each Router LSA WOULD contain as much as 16 bits count of undefined link-types. The initial assumption is that without clarifying information, that the undefined link-type does inflict routing changes. IMO, this should localize any possible routing iregularities to within 1 hop of the router(s) originating the unknown link-types. As new router LSA link-types accepted, accompaning should be a stated capability. With this capability, their would need to be some form of acceptance criteria as either dealing with the Router LSA and/or the adjancency formation. > For MTR (multi-topology routing) one should be smarter and actually > determine what has changed before doing an SPF. Anyway, this is somewhat > implementation specific. If I accept part of this reasoning, then lets fix it here! Then why shouldn't this draft RFC include a section 13.2 that specifies that some LSA body changes (ie: additions, subtraction, modification of unknown Router LSA link-types) do not necessitate the triggering of a SPF calc. Enough said... Mitchell Erblich ------------------- Acee Lindem wrote: > > Mitchell, > > See inline. > > Erblichs wrote: > > >Acee Lindem and et. al.. > > > > Yes and No.. > > I don't always agree with the general consensus. > > > > The stub area type is the easist to defend when > > it comes to the limited accepted link-types. > > However, it can and does apply to non stub areas, > > as presented below. > > > > Only 4 router LSA link-types are RFC2328 defined and should be > > used dealing with SPF calcs. If the undefines then > > deal with metric and monitoring, then I could > > understand the acceptance of unknowns, due to the > > fact that they can do no routing harm.. > > > > First, did any of your consensus see the > > two different Router LSA's with unknown link-types????? > > > > If we expound on on accepting, flooding, etc with > > your philosphy.. Then their is a RFC2328 section > > that hasn't been addressed. Section 13.2 specifies > > that when the body of a LSA has changed, it triggers > > a SPF calculation.... Did anybody see this??? > > > > By flooding the Router LSAs with unknown link-types > > any change with one unknown, the withdrawl of the > > unknown, etc.. will trigger SPF calculations.. > > > > The end result can't change, but must be run to > > be in Spec with the RFC. Do you really suggest running > > additional SPF calcs when the end result is the > > same?????? If they are stripped of unknowns this > > becomes a non-issue. Any change in the body dealing > > with unknown link-types is ignored, because only > > the stripped Router LSA is compared. > > > > > For MTR (multi-topology routing) one should be smarter and actually > determine what has changed before doing an SPF. Anyway, this is somewhat > implementation specific. > > > Thus, IMO, a default area type dealing with > > router link-type > > (due to the fact thar Router LSAs are area scope), > > MUST ONLY accept the RFC2328 4 defined link-types. > > > > > Then you are advocating rejecting the LSA? > > > > > A router can literally dump huge amounts of unknown > > Router LSA contents which according to you must be > > flooded throughout the area without being able to > > do any verification on the contents. It's just opaque > > data. > > > > > > > IFF new router link-types need to be supported, > > Shouldn't they be allowed as NEW capabilities??? > > With the new capabilities, they would need accompaning > > RFC information.. > > > > > We intend to be conservative in defining new link types and they will > require standards > action. > > > Thus, IMO this is the most conservative approach > > that could be taken. > > > > > > Mitchell Erblich > > -------------------------- > > > > > >Acee Lindem wrote: > > > > > >>Hi Mitchell, > >> > >>I don't think we want to do anything for stub areas. This draft was > >>a result of RFC2328 not specifying what an should be done with > >>unknown links types. We could have either reject the LSA or > >>ignore the unknown types. The opinions on the list were overwhelmingly > >>in favor of the latter. My opinion is that even with this draft we are > >>going to be extremely conservative in our introduction of new link > >>types. > >> > >>Furthermore, stub areas are protected from externally scoped > >>advertisements. Note that router LSAs are area scoped and presumely > >>each OSPF routing domain (and surely every area) is administratively > >>controlled by a single party. Hence, the network administrator should have > >>control over whether or not new links types are deployed in a stub area. > >> > >>Thanks, > >>Acee > >> > >>Erblichs wrote: > >> > >> > >> > >>>Group, > >>> > >>> Sorry about my late reply. I have a bad cold. :-( > >>> > >>> If I was to agree that we should process/forward > >>> unknown LSA link types, I think the wording specified > >>> in the draft is abit ambiguous.. > >>> > >>> Router LSA link-types 1,2, 3, and 4 are defined > >>> in RFC2328. However, a router may imploy a superset > >>> of link-types say supporting additional link-types, > >>> say link-type 5 for wireless links.. > >>> > >>> Thus, shouldn't the "should now read" deal with > >>> RFC 2328 Router LSA link-types unknowns and router-id > >>> router LSA link-type unknowns with link-type 6 or more????? > >>> > >>> So, does the "Unknown Link Types are ignored" (last > >>> sentance in ""2. Changes for OSPFv2"") deal > >>> with the RFC2328 unknowns or router-id router unknowns? > >>> I assume it is the later.. > >>> > >>> NOW, ......... > >>> > >>> When we have a stub area.. FYI, the original reason > >>> for stub areas (Moy OSPF books) was to reduce the > >>> memory requirments.. > >>> > >>> 1) simple case first.. > >>> > >>> Doesn't it make sense that if ALL the link-types > >>> within a ROUTER LSA are RFC2328 unknown that the LSA just > >>> consumes memory and CPU cycles.. Thus, in my opinion > >>> these LSAs should not be present in the routers within > >>> a stub area. > >>> > >>> or that all the routers within the area match > >>> the router-id router LSA link-type unknown.. > >>> > >>> I have been considering whether this ADJ should even > >>> be up if the router ONLY originates Router LSAs > >>> with unknown link-types??? Is it acting basicly > >>> as a passive adj? We can't send data packets over > >>> the link, but we should be able to recieve data > >>> packets.. Thus, I think we have a 1-way data link. > >>> > >>> 2) This falls into a subcategory of #1. If some of the > >>> link-types are known within a Router LSA, the unknowns > >>> should be stripped from the Router LSA. This should > >>> reduce the flooding overhead and memory requirements. > >>> It does require a memory copy to reduce the size of the > >>> router LSA. > >>> > >>> The assumption here is that the unknown link-types > >>> should be stripped. However, should they been originated > >>> in the first place??? Should displays (implimentation > >>> dependent) identify routers that generate router LSAs > >>> with unknown link-types? > >>> > >>> Thus, their are at least, LSA origination, flooding, > >>> and SPF issues that need to be addressed for the > >>> two definitions of "unknowns" and stub/not stub areas. > >>> > >>> Mitchell Erblich > >>> > >>> > >>> > >>> > >>> > > > > > > From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jan 26 20:29:55 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14236 for ; Wed, 26 Jan 2005 20:29:54 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.00F5DE12@cherry.ease.lsoft.com>; Wed, 26 Jan 2005 20:29:50 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 55229172 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 26 Jan 2005 20:29:48 -0500 Received: from 207.217.121.251 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 26 Jan 2005 20:29:47 -0500 Received: from user-2ivfjcm.dialup.mindspring.com ([165.247.205.150] helo=earthlink.net) by pop-a065d10.pas.sa.earthlink.net with esmtp (Exim 3.33 #1) id 1CtyTi-0002KQ-00 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 26 Jan 2005 17:29:47 -0800 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: <41F6DEAF.EF0B2C68@earthlink.net> <41F7C9D3.8080105@cisco.com> <41F8057F.B381430C@earthlink.net> <6.1.2.0.0.20050126161000.039c2c88@localhost> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <41F844EC.C6DFA7F7@earthlink.net> Date: Wed, 26 Jan 2005 17:33:32 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: draft-manral-ospf-router-lsa-unknown-type-02 To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Joel Halpern, I did NOT write the OSPF spec.. I am just reading what it says and it is incorrect with respect to unknown link-types. The spec says that if the LSA body has changed, trigger a SPF calc.. * Adding a unknown link-type to a Router LSA that didn't previously have one, * Removing a unknown link-type,,, * Adding additional unknowns... * Changing a unknown from one unknown to another unknown.. All these are changes to the LSA body and would nessitate a SPF calc according to the SPEC. Since, we are addressing unknowns within this draft RFC, I would expect us to specify this an an exception to the section, 13.2.. Mitchell Erblich ---------------- "Joel M. Halpern" wrote: > > Remember that the implementation of the calculation is a local matter. > In this case, the implementation can be "use the previous result" and it > will still be consistent with the spec. > > Yours, > Joel M. Halpern > > At 04:02 PM 1/26/2005, you wrote: > > By flooding the Router LSAs with unknown link-types > > any change with one unknown, the withdrawl of the > > unknown, etc.. will trigger SPF calculations.. > > > > The end result can't change, but must be run to > > be in Spec with the RFC. Do you really suggest running > > additional SPF calcs when the end result is the > > same?????? From owner-ospf@PEACH.EASE.LSOFT.COM Thu Jan 27 06:23:29 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17605 for ; Thu, 27 Jan 2005 06:23:28 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.00F5E905@cherry.ease.lsoft.com>; Thu, 27 Jan 2005 6:23:26 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 55278851 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 27 Jan 2005 06:23:24 -0500 Received: from 63.197.255.158 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 27 Jan 2005 06:23:22 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: draft-manral-ospf-router-lsa-unknown-type-02 thread-index: AcUEERKComTst9WOQ7iTFlPtKxhvbAAUXCYw Message-ID: Date: Thu, 27 Jan 2005 03:31:52 -0800 Reply-To: Mailing List Sender: Mailing List From: Vishwas Manral Subject: Re: draft-manral-ospf-router-lsa-unknown-type-02 To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Hi Mitchell, From the holistic perspective it is clear that we should not calculate SPF if we know it will not cause any change in the Shortest Path Tree and that is where (I guess everyone is coming from). However I agree Section 13.2 talks about the always calculating the routes from the beginning, if a router LSA's content changes. It also tells of conditions in which case SPF calculation is not done.=20 "The contents of the new LSA should be compared to the old instance, if present. If there is no difference, there is no need to recalculate the routing table." I agree we should specify that a change in the type should not cause the SPF to be run again, and that should be specified as an exceptional condition. I agree it's a good point. Thanks, Vishwas -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Erblichs Sent: Thursday, January 27, 2005 7:04 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: draft-manral-ospf-router-lsa-unknown-type-02 Joel Halpern, I did NOT write the OSPF spec.. I am just reading what it says and it is incorrect with respect to unknown link-types. The spec says that if the LSA body has changed, trigger a SPF calc.. * Adding a unknown link-type to a Router LSA that didn't previously have one, * Removing a unknown link-type,,, * Adding additional unknowns... * Changing a unknown from one unknown to another unknown.. All these are changes to the LSA body and would nessitate a SPF calc according to the SPEC. Since, we are addressing unknowns within this draft RFC, I would expect us to specify this an an exception to the section, 13.2.. Mitchell Erblich ---------------- "Joel M. Halpern" wrote: >=20 > Remember that the implementation of the calculation is a local matter. > In this case, the implementation can be "use the previous result" and it > will still be consistent with the spec. >=20 > Yours, > Joel M. Halpern >=20 > At 04:02 PM 1/26/2005, you wrote: > > By flooding the Router LSAs with unknown link-types > > any change with one unknown, the withdrawl of the > > unknown, etc.. will trigger SPF calculations.. > > > > The end result can't change, but must be run to > > be in Spec with the RFC. Do you really suggest running > > additional SPF calcs when the end result is the > > same?????? From owner-ospf@PEACH.EASE.LSOFT.COM Fri Jan 28 09:08:11 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02442 for ; Fri, 28 Jan 2005 09:08:10 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.00F606F5@cherry.ease.lsoft.com>; Fri, 28 Jan 2005 9:08:06 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 55475996 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 28 Jan 2005 09:08:04 -0500 Received: from 203.199.83.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 28 Jan 2005 09:08:03 -0500 Received: (qmail 18017 invoked by uid 510); 28 Jan 2005 14:09:34 -0000 Received: from unknown (203.126.136.223) by rediffmail.com via HTTP; 28 jan 2005 14:09:34 -0000 MIME-Version: 1.0 Content-type: multipart/alternative; boundary="Next_1106921374---0-203.199.83.148-18012" Message-ID: <20050128140934.18015.qmail@webmail26.rediffmail.com> Date: Fri, 28 Jan 2005 14:09:34 -0000 Reply-To: Mailing List Sender: Mailing List From: Vivek Dubey Subject: draft-ietf-ospf-te-node-addr-01 To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This is a multipart mime message --Next_1106921374---0-203.199.83.148-18012 Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Section 3=0A---------=0AThe proposed solution is to advertise the local add= resses of a router=0Ain a new OSPF TE LSA node attribute TLV=0A=0Avivek> Th= is TLV is currently proposed to be part of OSPF TE LSA (Opaque Type 10). Si= nce the information advertised through this TLV=0Ais not related to OSPF TE= , rather it's more of router attribue(s), should it not be part of OSPF RI = Opaque LSA(draft-ietf-ospf-cap-05) with TLV scope to be Type-11 Opaque LSA.= =0A=0AThanks=0AVivek=0A=0A --Next_1106921374---0-203.199.83.148-18012 Content-type: text/html; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

=0ASection 3
=0A---------
=0AThe proposed solution is to advertise= the local addresses of a router
=0Ain a new OSPF TE LSA node attribute = TLV
=0A
=0Avivek> This TLV is currently proposed to be part of OSP= F TE LSA (Opaque Type 10). Since the information advertised through this TL= V
=0Ais not related to OSPF TE, rather it's more of router attribue(s), = should it not be part of OSPF RI Opaque LSA(draft-ietf-ospf-cap-05) with TL= V scope to be Type-11 Opaque LSA.
=0A
=0AThanks
=0AVivek
=0A=0A=0A

=0A

=0A=0A --Next_1106921374---0-203.199.83.148-18012-- From owner-ospf@PEACH.EASE.LSOFT.COM Fri Jan 28 11:45:47 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17174 for ; Fri, 28 Jan 2005 11:45:42 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.00F609E0@cherry.ease.lsoft.com>; Fri, 28 Jan 2005 11:45:41 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 55491914 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 28 Jan 2005 11:45:38 -0500 Received: from 64.102.122.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 28 Jan 2005 11:45:38 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 28 Jan 2005 11:54:46 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j0SGjaoA014700 for ; Fri, 28 Jan 2005 11:45:36 -0500 (EST) Received: from [128.107.178.230] (dhcp-128-107-178-230.cisco.com [128.107.178.230]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BEX57478; Fri, 28 Jan 2005 08:45:35 -0800 (PST) User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <20050128140934.18015.qmail@webmail26.rediffmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <41FA6C2F.9040605@cisco.com> Date: Fri, 28 Jan 2005 11:45:35 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: draft-ietf-ospf-te-node-addr-01 To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <20050128140934.18015.qmail@webmail26.rediffmail.com> Precedence: list Content-Transfer-Encoding: 7bit Hello Vivek, Vivek Dubey wrote: > Section 3 > --------- > The proposed solution is to advertise the local addresses of a router > in a new OSPF TE LSA node attribute TLV > > vivek> This TLV is currently proposed to be part of OSPF TE LSA > (Opaque Type 10). Since the information advertised through this TLV > is not related to OSPF TE, > Quite the contrary, the address is to be used as an endpoint for TE tunnels. > rather it's more of router attribue(s), should it not be part of OSPF > RI Opaque LSA(draft-ietf-ospf-cap-05) with TLV scope to be Type-11 > Opaque LSA. > Nope. > > Thanks > Vivek > > > > Not on this list, the shortest path always wins ;^) Acee From owner-ospf@PEACH.EASE.LSOFT.COM Sat Jan 29 00:18:58 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25975 for ; Sat, 29 Jan 2005 00:18:56 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.00F61B18@cherry.ease.lsoft.com>; Sat, 29 Jan 2005 0:18:54 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 55554181 for OSPF@PEACH.EASE.LSOFT.COM; Sat, 29 Jan 2005 00:18:41 -0500 Received: from 206.190.39.208 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sat, 29 Jan 2005 00:18:41 -0500 Received: (qmail 96680 invoked by uid 60001); 29 Jan 2005 05:18:41 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=rsifA/tecjgKZMkoEOdLjeYp3IhpWkmWeLUgrCNfYlpjGt2eV6VHPrl/dWtu/2TavfYBDWSPdtV5mb/8GnsrZ7KC3IJxVNME20nI75M3JSvYfFSZnItYjAzNWxDN1bRwC/zft/rA0G3s8TRpLS0TY9NRj04/7H4sDa67hhgvXn8= ; Received: from [204.154.128.112] by web53105.mail.yahoo.com via HTTP; Fri, 28 Jan 2005 21:18:41 PST MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20050129051841.96678.qmail@web53105.mail.yahoo.com> Date: Fri, 28 Jan 2005 21:18:41 -0800 Reply-To: Mailing List Sender: Mailing List Comments: DomainKeys? See http://antispam.yahoo.com/domainkeys From: John Pecola Subject: OSPFv2 db-exchange To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list In this setup (OSPFv2), following sequence of events take place - R1--------Pt-to-Pt-------R2 1. Adjacency between R1 and R2 goes down 2. R1 postpones re-origination of its router lsa because it did so less than minLSInterval before 3. R1 and R2 go into exchange state 4. R1 sends the copy of exisiting router-lsa in its db description packet 5. R2 already has this copy and therefore does not request for it (Sec13.1 rfc 2328) 6. After minLSInterval, R1 re-originates its router lsa 7. R2 assumes it to be the same as its existing copy (sec 13.2) and does not run its SPF. This might cause an inconsistent routing table on R2. What am I missing in the above sequence? Thanks John __________________________________ Do you Yahoo!? Yahoo! Mail - Find what you need with new enhanced search. http://info.mail.yahoo.com/mail_250 From owner-ospf@PEACH.EASE.LSOFT.COM Sat Jan 29 02:17:35 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16262 for ; Sat, 29 Jan 2005 02:17:34 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00F61CD9@cherry.ease.lsoft.com>; Sat, 29 Jan 2005 2:17:33 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 55559699 for OSPF@PEACH.EASE.LSOFT.COM; Sat, 29 Jan 2005 02:17:31 -0500 Received: from 203.199.83.147 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sat, 29 Jan 2005 02:17:31 -0500 Received: (qmail 11225 invoked by uid 510); 29 Jan 2005 07:19:01 -0000 Received: from unknown (203.126.136.220) by rediffmail.com via HTTP; 29 jan 2005 07:19:01 -0000 MIME-Version: 1.0 Content-type: multipart/alternative; boundary="Next_1106983141---0-203.199.83.147-11220" Message-ID: <20050129071901.11224.qmail@webmail25.rediffmail.com> Date: Sat, 29 Jan 2005 07:19:01 -0000 Reply-To: Mailing List Sender: Mailing List From: Vivek Dubey Subject: Re: draft-ietf-ospf-te-node-addr-01 To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This is a multipart mime message --Next_1106983141---0-203.199.83.147-11220 Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Acee,=0APls see comments inline.=0A=0A>Quite the contrary, the address i= s to be used as an endpoint for TE >tunnels=0Avivek> Agreed. Let me clarify= what i meant (probably conveyed it wrongly). To quote from draft:=0A=0ASec= tion 1: 3rd Para=0A--------------------=0ACurrently routers in an OSPF netw= ork can only use CSPF to=0Acompute MPLS TE LSPs to the router ID or the loc= al addresses of TE=0Aenabled links of a remote router. This restriction ari= ses because=0AOSPF TE extensions [OSPF-TE, OSPFv3-TE] only advertise the ro= uter ID=0Aand the local addresses of TE enabled links of a given router. Ot= her=0Arouters in the network can populate their traffic engineering=0Adatab= ase (TED) with these local addresses belonging to the=0Aadvertising router.= However they cannot populate the TED with other=0Alocal addresses of the a= dvertising router i.e. loopback and non-TE=0Ainterface addresses.=0A=0Avive= k> Than this information falls more in the domain of "router information" i= nstead of router(s) TE info/capabilities. Further is there any particular r= eason to limit this information to area scope?=0A=0A>Not on this list, the = shortest path always wins ;^)=0Avivek> Agreed.=0A=0AThanks=0AVivek=0A=0A=0A= =0A=0A=0A --Next_1106983141---0-203.199.83.147-11220 Content-type: text/html; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

=0AHi Acee,
=0APls see comments inline.
=0A
=0A>Quite the co= ntrary, the address is to be used as an endpoint for TE >tunnels
=0Av= ivek> Agreed. Let me clarify what i meant (probably conveyed it wrongly)= . To quote from draft:
=0A
=0ASection 1: 3rd Para
=0A-------------= -------
=0ACurrently routers in an OSPF network can only use CSPF to
= =0Acompute MPLS TE LSPs to the router ID or the local addresses of TE
= =0Aenabled links of a remote router. This restriction arises because
=0A= OSPF TE extensions [OSPF-TE, OSPFv3-TE] only advertise the router ID
=0A= and the local addresses of TE enabled links of a given router. Other
=0A= routers in the network can populate their traffic engineering
=0Adatabas= e (TED) with these local addresses belonging to the
=0Aadvertising route= r. However they cannot populate the TED with other
=0Alocal addresses of= the advertising router i.e. loopback and non-TE
=0Ainterface addresses.=
=0A
=0Avivek> Than this information falls more in the domain of &= quot;router information" instead of router(s) TE info/capabilities. Fu= rther is there any particular reason to limit this information to area scop= e?
=0A
=0A>Not on this list, the shortest path always wins ;^)
= =0Avivek> Agreed.
=0A
=0AThanks
=0AVivek
=0A
=0A
=0A=0A
=0A
=0A=0A

=0A

=0A=0A --Next_1106983141---0-203.199.83.147-11220-- From owner-ospf@PEACH.EASE.LSOFT.COM Sat Jan 29 05:04:06 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26859 for ; Sat, 29 Jan 2005 05:04:05 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.00F61E4A@cherry.ease.lsoft.com>; Sat, 29 Jan 2005 5:04:00 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 55567015 for OSPF@PEACH.EASE.LSOFT.COM; Sat, 29 Jan 2005 05:03:57 -0500 Received: from 203.197.138.222 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sat, 29 Jan 2005 05:03:56 -0500 Received: from kailash.future.futsoft.com (unverified [203.197.140.36]) by mail1.future.futsoft.com (Content Technologies SMTPRS 4.3.12) with ESMTP id for ; Sat, 29 Jan 2005 15:30:37 +0530 Received: from manishgs (manishgs.future.futsoft.com [10.203.113.5]) by kailash.future.futsoft.com (8.12.8/8.12.8) with SMTP id j0T9w15q007711 for ; Sat, 29 Jan 2005 15:28:02 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Message-ID: <005601c505e9$c7b872c0$0571cb0a@future.futsoft.com> Date: Sat, 29 Jan 2005 15:33:27 +0530 Reply-To: Mailing List Sender: Mailing List From: Manish Gupta Subject: Re: OSPFv2 db-exchange To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <20050129051841.96678.qmail@web53105.mail.yahoo.com> Precedence: list Content-Transfer-Encoding: 7bit Hi Joan, SPF needs to be run whenever router received a new LSA via flooding OR it's newly self-originated LSA installed in database. in your case due to MinLsaInterval you have not received router LSA from R1. but when adjacency goes down, R2 will generate a new instance of Router LSA in which Point-to-point link (link type 1, and Link Id as R1 router ID) should not be there by which R2 will know that R1 is nor reachable and it can calculate the correct routes. and when the adjacency become FULL R2 will again generate the router LSA with point-to-point link (link type 1, and Link Id as R1 router ID) by which it can caculate the correct routes. Regards Manish Gupta -----Original Message----- From: Mailing List [mailto:OSPF@peach.ease.lsoft.com]On Behalf Of John Pecola Sent: Saturday, 29 January 2005 10:49 AM To: OSPF@peach.ease.lsoft.com Subject: OSPFv2 db-exchange In this setup (OSPFv2), following sequence of events take place - R1--------Pt-to-Pt-------R2 1. Adjacency between R1 and R2 goes down 2. R1 postpones re-origination of its router lsa because it did so less than minLSInterval before 3. R1 and R2 go into exchange state 4. R1 sends the copy of exisiting router-lsa in its db description packet 5. R2 already has this copy and therefore does not request for it (Sec13.1 rfc 2328) 6. After minLSInterval, R1 re-originates its router lsa 7. R2 assumes it to be the same as its existing copy (sec 13.2) and does not run its SPF. This might cause an inconsistent routing table on R2. What am I missing in the above sequence? Thanks John __________________________________ Do you Yahoo!? Yahoo! Mail - Find what you need with new enhanced search. http://info.mail.yahoo.com/mail_250 *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** From owner-ospf@PEACH.EASE.LSOFT.COM Sat Jan 29 08:30:18 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09687 for ; Sat, 29 Jan 2005 08:30:18 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00F62287@cherry.ease.lsoft.com>; Sat, 29 Jan 2005 8:30:12 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 55612529 for OSPF@PEACH.EASE.LSOFT.COM; Sat, 29 Jan 2005 08:30:11 -0500 Received: from 64.102.122.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sat, 29 Jan 2005 08:30:11 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 29 Jan 2005 08:39:27 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j0TDU7oA007048 for ; Sat, 29 Jan 2005 08:30:07 -0500 (EST) Received: from [10.21.97.99] (sjc-vpn1-355.cisco.com [10.21.97.99]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BEY07150; Sat, 29 Jan 2005 05:30:06 -0800 (PST) User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <20050129051841.96678.qmail@web53105.mail.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <41FB8FDD.7080804@cisco.com> Date: Sat, 29 Jan 2005 08:30:05 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: OSPFv2 db-exchange To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <20050129051841.96678.qmail@web53105.mail.yahoo.com> Precedence: list Content-Transfer-Encoding: 7bit Hi John, John Pecola wrote: >In this setup (OSPFv2), following sequence of events >take place - > > R1--------Pt-to-Pt-------R2 > >1. Adjacency between R1 and R2 goes down >2. R1 postpones re-origination of its router lsa >because it did so less than minLSInterval before >3. R1 and R2 go into exchange state >4. R1 sends the copy of exisiting router-lsa in its db >description packet >5. R2 already has this copy and therefore does not >request for it (Sec13.1 rfc 2328) >6. After minLSInterval, R1 re-originates its router >lsa >7. R2 assumes it to be the same as its existing copy >(sec 13.2) and does not run its SPF. > > When R1 reoriginates its LSA it should a new sequence number (and most probably the checksum will change). Hence, R2 should interprete it as a more recent LSA and run its SPF. Thanks, Acee >This might cause an inconsistent routing table on R2. >What am I missing in the above sequence? > >Thanks >John > > > >__________________________________ >Do you Yahoo!? >Yahoo! Mail - Find what you need with new enhanced search. >http://info.mail.yahoo.com/mail_250 > > > From owner-ospf@PEACH.EASE.LSOFT.COM Sat Jan 29 08:40:51 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10232 for ; Sat, 29 Jan 2005 08:40:49 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.00F62230@cherry.ease.lsoft.com>; Sat, 29 Jan 2005 8:40:44 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 55613359 for OSPF@PEACH.EASE.LSOFT.COM; Sat, 29 Jan 2005 08:40:16 -0500 Received: from 64.102.122.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sat, 29 Jan 2005 08:40:16 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 29 Jan 2005 08:40:16 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j0TDeDW0028769 for ; Sat, 29 Jan 2005 08:40:14 -0500 (EST) Received: from [10.21.97.99] (sjc-vpn1-355.cisco.com [10.21.97.99]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BEY07234; Sat, 29 Jan 2005 05:40:12 -0800 (PST) User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <20050129071901.11224.qmail@webmail25.rediffmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <41FB923C.4070807@cisco.com> Date: Sat, 29 Jan 2005 08:40:12 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: draft-ietf-ospf-te-node-addr-01 To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <20050129071901.11224.qmail@webmail25.rediffmail.com> Precedence: list Content-Transfer-Encoding: 7bit Hi Vivek, Vivek Dubey wrote: > Hi Acee, > Pls see comments inline. > > >Quite the contrary, the address is to be used as an endpoint for TE > >tunnels > vivek> Agreed. Let me clarify what i meant (probably conveyed it > wrongly). To quote from draft: > > Section 1: 3rd Para > -------------------- > Currently routers in an OSPF network can only use CSPF to > compute MPLS TE LSPs to the router ID or the local addresses of TE > enabled links of a remote router. This restriction arises because > OSPF TE extensions [OSPF-TE, OSPFv3-TE] only advertise the router ID > and the local addresses of TE enabled links of a given router. Other > routers in the network can populate their traffic engineering > database (TED) with these local addresses belonging to the > advertising router. However they cannot populate the TED with other > local addresses of the advertising router i.e. loopback and non-TE > interface addresses. > I'm not sure what part of this is confusing. It says the local addresses are used to populate the traffic engineering database. Hence, I don't see why this TLV shouldn't be included in the TE LSAs. Can you indicate specifically what text you think needs to be changed? IMHO, there is value to keeping the TE information together in the TE LSAs. > > vivek> Than this information falls more in the domain of "router > information" instead of router(s) TE info/capabilities. Further is > there any particular reason to limit this information to area scope? > The current TE LSAs are area scoped. This is to be used for the TE application. > > >Not on this list, the shortest path always wins ;^) > vivek> Agreed. > > Thanks > Vivek > > > > > > > > From owner-ospf@PEACH.EASE.LSOFT.COM Sat Jan 29 11:47:31 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22477 for ; Sat, 29 Jan 2005 11:47:31 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00F6235C@cherry.ease.lsoft.com>; Sat, 29 Jan 2005 11:47:31 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 55625508 for OSPF@PEACH.EASE.LSOFT.COM; Sat, 29 Jan 2005 11:47:28 -0500 Received: from 203.197.138.222 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sat, 29 Jan 2005 11:47:27 -0500 Received: from kailash.future.futsoft.com (unverified [203.197.140.36]) by mail1.future.futsoft.com (Content Technologies SMTPRS 4.3.12) with ESMTP id for ; Sat, 29 Jan 2005 22:16:41 +0530 Received: from manishgs (manishgs.future.futsoft.com [10.203.113.5]) by kailash.future.futsoft.com (8.12.8/8.12.8) with SMTP id j0TGhC5q010353 for ; Sat, 29 Jan 2005 22:13:15 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Message-ID: <005e01c50622$635b26e0$0571cb0a@future.futsoft.com> Date: Sat, 29 Jan 2005 22:18:40 +0530 Reply-To: Mailing List Sender: Mailing List From: Manish Gupta Subject: Re: OSPFv2 db-exchange To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <41FB8FDD.7080804@cisco.com> Precedence: list Content-Transfer-Encoding: 7bit Hi Acee, i agree with you that when R1 reoriginates its LSA it should a new sequence number (and most probably the checksum will change) but why R2 should run the SPF if only sequence number or check sum is changed. say for example R1 and R2 are connected via point to point link. after every LSRefreshTime R1 and R2 will generate a new instance of LSAs. but there is no change in the network topology so why should we run the SPF. according to RFC 2328 section 13.2 :- When comparing an LSA to its previous instance, the following are all considered to be differences in contents: o The LSA's Options field has changed. o One of the LSA instances has LS age set to MaxAge, and the other does not. o The length field in the LSA header has changed. o The body of the LSA (i.e., anything outside the 20-byte LSA header) has changed. Note that this excludes changes in LS Sequence Number and LS Checksum. am i missing something ? Regards Manish Gupta -----Original Message----- From: Mailing List [mailto:OSPF@peach.ease.lsoft.com]On Behalf Of Acee Lindem Sent: Saturday, 29 January 2005 7:00 PM To: OSPF@peach.ease.lsoft.com Subject: Re: OSPFv2 db-exchange Hi John, John Pecola wrote: >In this setup (OSPFv2), following sequence of events >take place - > > R1--------Pt-to-Pt-------R2 > >1. Adjacency between R1 and R2 goes down >2. R1 postpones re-origination of its router lsa >because it did so less than minLSInterval before >3. R1 and R2 go into exchange state >4. R1 sends the copy of exisiting router-lsa in its db >description packet >5. R2 already has this copy and therefore does not >request for it (Sec13.1 rfc 2328) >6. After minLSInterval, R1 re-originates its router >lsa >7. R2 assumes it to be the same as its existing copy >(sec 13.2) and does not run its SPF. > > When R1 reoriginates its LSA it should a new sequence number (and most probably the checksum will change). Hence, R2 should interprete it as a more recent LSA and run its SPF. Thanks, Acee >This might cause an inconsistent routing table on R2. >What am I missing in the above sequence? > >Thanks >John > > > >__________________________________ >Do you Yahoo!? >Yahoo! Mail - Find what you need with new enhanced search. >http://info.mail.yahoo.com/mail_250 > > > *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** From owner-ospf@PEACH.EASE.LSOFT.COM Sat Jan 29 14:45:45 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06790 for ; Sat, 29 Jan 2005 14:45:42 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.00F626E3@cherry.ease.lsoft.com>; Sat, 29 Jan 2005 14:45:37 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 55636005 for OSPF@PEACH.EASE.LSOFT.COM; Sat, 29 Jan 2005 14:45:33 -0500 Received: from 66.129.224.36 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sat, 29 Jan 2005 14:45:32 -0500 Received: from sapphire.juniper.net (localhost [127.0.0.1]) by sapphire.juniper.net (8.12.11/8.12.3) with ESMTP id j0TJjWtk040902 for ; Sat, 29 Jan 2005 11:45:32 -0800 (PST) (envelope-from rahul@juniper.net) Received: from localhost (rahul@localhost) by sapphire.juniper.net (8.12.11/8.12.3/Submit) with ESMTP id j0TJjW8b040899 for ; Sat, 29 Jan 2005 11:45:32 -0800 (PST) X-Authentication-Warning: sapphire.juniper.net: rahul owned process doing -bs References: <20050129071901.11224.qmail@webmail25.rediffmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: <20050129114317.U40278@sapphire.juniper.net> Date: Sat, 29 Jan 2005 11:45:32 -0800 Reply-To: Mailing List Sender: Mailing List From: Rahul Aggarwal Subject: Re: draft-ietf-ospf-te-node-addr-01 To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <20050129071901.11224.qmail@webmail25.rediffmail.com> Precedence: list Hi Vivek, On Sat, 29 Jan 2005, Vivek Dubey wrote: > Hi Acee, Pls see comments inline. >Quite the contrary, the address is to be used as an endpoint for TE >tunnels vivek> Agreed. Let me clarify what i meant (probably conveyed it wrongly). To quote from draft: Section 1: 3rd Para -------------------- Currently routers in an OSPF network can only use CSPF to compute MPLS TE LSPs to the router ID or the local addresses of TE enabled links of a remote router. This restriction arises because OSPF TE extensions [OSPF-TE, OSPFv3-TE] only advertise the router ID and the local addresses of TE enabled links of a given router. Other routers in the network can populate their traffic engineering database (TED) with these local addresses belonging to the advertising router. However they cannot populate the TED with other local addresses of the advertising router i.e. loopback and non-TE interface addresses. vivek> Than this information falls more in the domain of "router information" instead of router(s) TE >info/capabilities. Further is there any particular reason to limit this > information to area scope? This is TE specific information and should be advertised as part of the TE LSAs. It is limited to area scope as TE information, as defined currently, is area scoped. rahul >Not on this list, the shortest path always wins ;^) vivek> Agreed. Thanks Vivek From owner-ospf@PEACH.EASE.LSOFT.COM Sat Jan 29 15:07:01 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08341 for ; Sat, 29 Jan 2005 15:07:01 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00F62670@cherry.ease.lsoft.com>; Sat, 29 Jan 2005 15:07:01 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 55637319 for OSPF@PEACH.EASE.LSOFT.COM; Sat, 29 Jan 2005 15:06:59 -0500 Received: from 206.190.39.205 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sat, 29 Jan 2005 15:06:59 -0500 Received: (qmail 58340 invoked by uid 60001); 29 Jan 2005 20:06:59 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=06tABOjCRgEOWH5aSn3pD/uRDo3ruQ9h8IGRxMDfJ+arttEuvGS7wJNXVDCZlAVi+JEh7WDKpdYSUWGlK9G4Zo0ZHImv7LLPf8Cg0kD600tfm3C5WdWlFBeDpUAdfV2lSauuiVc6wwspNuUV7jK0owC18DFCtS0Hj5tZr5YJlNA= ; Received: from [68.122.42.116] by web53102.mail.yahoo.com via HTTP; Sat, 29 Jan 2005 12:06:59 PST MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20050129200659.58338.qmail@web53102.mail.yahoo.com> Date: Sat, 29 Jan 2005 12:06:59 -0800 Reply-To: Mailing List Sender: Mailing List Comments: DomainKeys? See http://antispam.yahoo.com/domainkeys From: John Pecola Subject: Re: OSPFv2 db-exchange To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <005601c505e9$c7b872c0$0571cb0a@future.futsoft.com> Precedence: list Manish, R2 may also go through similar sequence that R1 went through. When the adjacency went down, R2 was unable to re-originate its router LSA because of minLSInterval. When it eventually does, adjacency is already back up, and so R2 should see its router lsa unchanged (Sec 13.2) and not re-install it (and not run its routing table calculation). Is this assumption correct? Thanks John --- Manish Gupta wrote: > Hi Joan, > > SPF needs to be run whenever router received a new > LSA via flooding OR > it's newly self-originated LSA installed in > database. > in your case due to MinLsaInterval you have not > received router LSA from R1. > but when adjacency goes down, R2 will generate a new > instance of Router LSA > in which Point-to-point link (link type 1, and Link > Id as R1 router ID) > should not be there by which R2 will know that > R1 is nor reachable and it can calculate the correct > routes. > and when the adjacency become FULL R2 will again > generate the router LSA > with point-to-point link (link type 1, and Link Id > as R1 router ID) by which > it can caculate the correct routes. > > Regards > Manish Gupta > > > -----Original Message----- > From: Mailing List > [mailto:OSPF@peach.ease.lsoft.com]On Behalf Of John > Pecola > Sent: Saturday, 29 January 2005 10:49 AM > To: OSPF@peach.ease.lsoft.com > Subject: OSPFv2 db-exchange > > > In this setup (OSPFv2), following sequence of events > take place - > > R1--------Pt-to-Pt-------R2 > > 1. Adjacency between R1 and R2 goes down > 2. R1 postpones re-origination of its router lsa > because it did so less than minLSInterval before > 3. R1 and R2 go into exchange state > 4. R1 sends the copy of exisiting router-lsa in its > db > description packet > 5. R2 already has this copy and therefore does not > request for it (Sec13.1 rfc 2328) > 6. After minLSInterval, R1 re-originates its router > lsa > 7. R2 assumes it to be the same as its existing copy > (sec 13.2) and does not run its SPF. > > This might cause an inconsistent routing table on > R2. > What am I missing in the above sequence? > > Thanks > John > > > > __________________________________ > Do you Yahoo!? > Yahoo! Mail - Find what you need with new enhanced > search. > http://info.mail.yahoo.com/mail_250 > > > > *************************************************************************** > This message is proprietary to Future Software > Limited (FSL) > and is intended solely for the use of the individual > to whom it > is addressed. It may contain privileged or > confidential information > and should not be circulated or used for any purpose > other than for > what it is intended. > > If you have received this message in error, please > notify the > originator immediately. If you are not the intended > recipient, > you are notified that you are strictly prohibited > from using, > copying, altering, or disclosing the contents of > this message. > FSL accepts no responsibility for loss or damage > arising from > the use of the information transmitted by this email > including > damage from virus. > *************************************************************************** > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From owner-ospf@PEACH.EASE.LSOFT.COM Sat Jan 29 18:43:34 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24533 for ; Sat, 29 Jan 2005 18:43:34 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00F62CAC@cherry.ease.lsoft.com>; Sat, 29 Jan 2005 18:43:34 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 55650636 for OSPF@PEACH.EASE.LSOFT.COM; Sat, 29 Jan 2005 18:43:33 -0500 Received: from 64.233.170.201 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sat, 29 Jan 2005 18:33:33 -0500 Received: by rproxy.gmail.com with SMTP id f1so648423rne for ; Sat, 29 Jan 2005 15:33:33 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=AS8xINvAkG1Fv5w+KIcGxR8WEsLJgSX66QLMGsMKQOavX+vJz3xgZ9Pxl065edG4nwfxoDjnJnPO7ZhG3MUCrZhZ1e2yAeUuHJvtU6iNW/VEyLmTIaoL63Fz/7FHL/TXazKfFKjEMwufq5rm/DwYYnhtO+ZA5Zhlywvm7Ft6gnk= Received: by 10.38.74.34 with SMTP id w34mr52883rna; Sat, 29 Jan 2005 15:32:44 -0800 (PST) Received: by 10.38.151.76 with HTTP; Sat, 29 Jan 2005 15:32:44 -0800 (PST) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20050129051841.96678.qmail@web53105.mail.yahoo.com> Message-ID: Date: Sat, 29 Jan 2005 18:32:44 -0500 Reply-To: Mailing List Sender: Mailing List From: Ramanan N Subject: Re: OSPFv2 db-exchange To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <20050129051841.96678.qmail@web53105.mail.yahoo.com> Precedence: list Content-Transfer-Encoding: 7bit Please see inlined ! On Fri, 28 Jan 2005 21:18:41 -0800, John Pecola wrote: > In this setup (OSPFv2), following sequence of events > take place - > > R1--------Pt-to-Pt-------R2 > > 1. Adjacency between R1 and R2 goes down > 2. R1 postpones re-origination of its router lsa > because it did so less than minLSInterval before > 3. R1 and R2 go into exchange state > 4. R1 sends the copy of exisiting router-lsa in its db > description packet > 5. R2 already has this copy and therefore does not > request for it (Sec13.1 rfc 2328) > 6. After minLSInterval, R1 re-originates its router > lsa > 7. R2 assumes it to be the same as its existing copy > (sec 13.2) and does not run its SPF. > > This might cause an inconsistent routing table on R2. John, I didnt get this. When R1 has reoriginated the router LSA with a higher seq num, the contents would not have changed from that of the prev one. So, R2 would have installed the R1's new lsa in R2's database, Since the contents have not changed, SPF is not run immediately. when the SPF is run later, there should not be any inconsistency in the routing table. > What am I missing in the above sequence? Or did I too miss ? > > Thanks > John > > > __________________________________ > Do you Yahoo!? > Yahoo! Mail - Find what you need with new enhanced search. > http://info.mail.yahoo.com/mail_250 > From owner-ospf@PEACH.EASE.LSOFT.COM Sat Jan 29 21:21:53 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05469 for ; Sat, 29 Jan 2005 21:21:52 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.00F62E4A@cherry.ease.lsoft.com>; Sat, 29 Jan 2005 21:21:52 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 55658776 for OSPF@PEACH.EASE.LSOFT.COM; Sat, 29 Jan 2005 21:21:49 -0500 Received: from 207.217.121.251 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sat, 29 Jan 2005 21:21:49 -0500 Received: from user-2ivfim4.dialup.mindspring.com ([165.247.202.196] helo=earthlink.net) by pop-a065d10.pas.sa.earthlink.net with esmtp (Exim 3.33 #1) id 1Cv4ii-0007ES-00 for OSPF@PEACH.EASE.LSOFT.COM; Sat, 29 Jan 2005 18:21:49 -0800 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: <20050129051841.96678.qmail@web53105.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <41FC447D.555BF35@earthlink.net> Date: Sat, 29 Jan 2005 18:20:45 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: OSPFv2 db-exchange To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit John Pecola, The below sequcence really doesn't make sense, because R1 & R2 cannot go into exhange state while they are no longer neighbors., so I must assume that they became 2-way before echange. AA - Assuming that R1 & R2 have other neighbors/adjs, when the adjcency went down between the two of them, they each would re-orginate their router LSAs no longer declaring the link to the other router (R1 or R2) link up TO THEIR other nbr routers. BB - If R1 and R2 didn't have other nbrs, then they could keep the original past nbr's LSA in their database because it can't be used without the adj to the nbr via the SPF calc. When the link comes back up, they will maybe form a 2-way nbr state, and move into exchange state. At this point, I think you assume it's BB. They should each request and recieve the older LSA version. They each should increment the sequence of their respective router LSA and send it in a LS Update pkt. I believe if my memory serves me, one of Moy's OSPF book's he has the restart seq with router's echanging the old LSAs, and then Updating with a newer LSA via an increment of its instance. This violates your #5. Some implimentations may scan for no longer valid LSAs and remove them. This would easily be the case if 1 hour had passed between your (#1 and #3) since the LSA was updated. This would then result in the new LSAs being sent after Requests. FYI: Some implimentations will wait for some period of time iff a link's history has a quality of UNstableness, before exchange begins. The MinLSInterval really applies when the LSA changes in a significant manner and in theory reduces the freq of the repeated flooding of a particular LSA. However, with respect to router's specified in router and network LSAs, they in theory require full adj before being specified in the LSAs. This requires these nbr to be updated with a additional LSA. Mitchell Erblich John Pecola wrote: > > In this setup (OSPFv2), following sequence of events > take place - > > R1--------Pt-to-Pt-------R2 > > 1. Adjacency between R1 and R2 goes down > 2. R1 postpones re-origination of its router lsa > because it did so less than minLSInterval before > 3. R1 and R2 go into exchange state > 4. R1 sends the copy of exisiting router-lsa in its db > description packet > 5. R2 already has this copy and therefore does not > request for it (Sec13.1 rfc 2328) > 6. After minLSInterval, R1 re-originates its router > lsa > 7. R2 assumes it to be the same as its existing copy > (sec 13.2) and does not run its SPF. > > This might cause an inconsistent routing table on R2. > What am I missing in the above sequence? > > Thanks > John > > > __________________________________ > Do you Yahoo!? > Yahoo! Mail - Find what you need with new enhanced search. > http://info.mail.yahoo.com/mail_250 From owner-ospf@PEACH.EASE.LSOFT.COM Mon Jan 31 08:08:40 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25018 for ; Mon, 31 Jan 2005 08:08:38 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.00F6502D@cherry.ease.lsoft.com>; Mon, 31 Jan 2005 8:08:34 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 55850922 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 31 Jan 2005 08:08:25 -0500 Received: from 64.102.122.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 31 Jan 2005 08:08:25 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 31 Jan 2005 08:08:26 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j0VD8LW0029685 for ; Mon, 31 Jan 2005 08:08:22 -0500 (EST) Received: from [10.82.217.100] (rtp-vpn3-354.cisco.com [10.82.217.100]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BEY51425; Mon, 31 Jan 2005 05:08:23 -0800 (PST) User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <005e01c50622$635b26e0$0571cb0a@future.futsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <41FE2DC9.4090602@cisco.com> Date: Mon, 31 Jan 2005 08:08:25 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: OSPFv2 db-exchange To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <005e01c50622$635b26e0$0571cb0a@future.futsoft.com> Precedence: list Content-Transfer-Encoding: 7bit Manish Gupta wrote: >Hi Acee, > i agree with you that when R1 reoriginates its LSA it should a new >sequence number (and most >probably the checksum will change) > > Hi Manish, I guess there are different interpretations for the original post. My assumption was that the original LSA had changes and was delayed due to MinLSInterval. Thanks, Acee >but why R2 should run the SPF if only sequence number or check sum is >changed. > >say for example R1 and R2 are connected via point to point link. >after every LSRefreshTime R1 and R2 will generate a new instance of LSAs. >but there is no change in the network topology so why should we run the SPF. > >according to RFC 2328 section 13.2 :- > > When comparing an LSA to its previous instance, > the following are all considered to be differences in contents: > > o The LSA's Options field has changed. > > o One of the LSA instances has LS age set to MaxAge, and > the other does not. > > o The length field in the LSA header has changed. > > o The body of the LSA (i.e., anything outside the 20-byte > LSA header) has changed. Note that this excludes changes > in LS Sequence Number and LS Checksum. > > >am i missing something ? > >Regards >Manish Gupta > > > > > > >-----Original Message----- >From: Mailing List [mailto:OSPF@peach.ease.lsoft.com]On Behalf Of Acee >Lindem >Sent: Saturday, 29 January 2005 7:00 PM >To: OSPF@peach.ease.lsoft.com >Subject: Re: OSPFv2 db-exchange > > >Hi John, > > >John Pecola wrote: > > > >>In this setup (OSPFv2), following sequence of events >>take place - >> >> R1--------Pt-to-Pt-------R2 >> >>1. Adjacency between R1 and R2 goes down >>2. R1 postpones re-origination of its router lsa >>because it did so less than minLSInterval before >>3. R1 and R2 go into exchange state >>4. R1 sends the copy of exisiting router-lsa in its db >>description packet >>5. R2 already has this copy and therefore does not >>request for it (Sec13.1 rfc 2328) >>6. After minLSInterval, R1 re-originates its router >>lsa >>7. R2 assumes it to be the same as its existing copy >>(sec 13.2) and does not run its SPF. >> >> >> >> >When R1 reoriginates its LSA it should a new sequence number (and most >probably the checksum will change). Hence, R2 should interprete it as a more >recent LSA and run its SPF. > >Thanks, >Acee > > > > >>This might cause an inconsistent routing table on R2. >>What am I missing in the above sequence? >> >>Thanks >>John >> >> >> >>__________________________________ >>Do you Yahoo!? >>Yahoo! Mail - Find what you need with new enhanced search. >>http://info.mail.yahoo.com/mail_250 >> >> >> >> >> > > > >*************************************************************************** >This message is proprietary to Future Software Limited (FSL) >and is intended solely for the use of the individual to whom it >is addressed. It may contain privileged or confidential information >and should not be circulated or used for any purpose other than for >what it is intended. > >If you have received this message in error, please notify the >originator immediately. If you are not the intended recipient, >you are notified that you are strictly prohibited from using, >copying, altering, or disclosing the contents of this message. >FSL accepts no responsibility for loss or damage arising from >the use of the information transmitted by this email including >damage from virus. >*************************************************************************** > > > From owner-ospf@PEACH.EASE.LSOFT.COM Mon Jan 31 08:19:53 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28080 for ; Mon, 31 Jan 2005 08:19:52 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00F64F8F@cherry.ease.lsoft.com>; Mon, 31 Jan 2005 8:19:52 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 55851860 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 31 Jan 2005 08:19:49 -0500 Received: from 64.102.122.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 31 Jan 2005 08:19:49 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 31 Jan 2005 08:29:30 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j0VDJkW0001951 for ; Mon, 31 Jan 2005 08:19:46 -0500 (EST) Received: from [10.82.217.100] (rtp-vpn3-354.cisco.com [10.82.217.100]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BEY51868; Mon, 31 Jan 2005 05:19:47 -0800 (PST) User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <20050129200659.58338.qmail@web53102.mail.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <41FE3075.8080005@cisco.com> Date: Mon, 31 Jan 2005 08:19:49 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: OSPFv2 db-exchange To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <20050129200659.58338.qmail@web53102.mail.yahoo.com> Precedence: list Content-Transfer-Encoding: 7bit Hi John, Now I think I understand your scenario - see inline. John Pecola wrote: >Manish, > >R2 may also go through similar sequence that R1 went >through. When the adjacency went down, R2 was unable >to re-originate its router LSA because of >minLSInterval. When it eventually does, adjacency is >already back up, and so R2 should see its router lsa >unchanged (Sec 13.2) and not re-install it > In any case, it should re-install it in the database since it is more recent. > (and not >run its routing table calculation). Is this assumption >correct? > > It need not re-run the routing calculation if the LSA is unchanged. However, it will definitely re-run it's routing calculation when it goes to FULL state with R1. >Thanks >John > >--- Manish Gupta wrote: > > > >>Hi Joan, >> >>SPF needs to be run whenever router received a new >>LSA via flooding OR >>it's newly self-originated LSA installed in >>database. >>in your case due to MinLsaInterval you have not >>received router LSA from R1. >>but when adjacency goes down, R2 will generate a new >>instance of Router LSA >>in which Point-to-point link (link type 1, and Link >>Id as R1 router ID) >>should not be there by which R2 will know that >>R1 is nor reachable and it can calculate the correct >>routes. >>and when the adjacency become FULL R2 will again >>generate the router LSA >>with point-to-point link (link type 1, and Link Id >>as R1 router ID) by which >>it can caculate the correct routes. >> >>Regards >>Manish Gupta >> >> >>-----Original Message----- >>From: Mailing List >>[mailto:OSPF@peach.ease.lsoft.com]On Behalf Of John >>Pecola >>Sent: Saturday, 29 January 2005 10:49 AM >>To: OSPF@peach.ease.lsoft.com >>Subject: OSPFv2 db-exchange >> >> >>In this setup (OSPFv2), following sequence of events >>take place - >> >> R1--------Pt-to-Pt-------R2 >> >>1. Adjacency between R1 and R2 goes down >>2. R1 postpones re-origination of its router lsa >>because it did so less than minLSInterval before >>3. R1 and R2 go into exchange state >>4. R1 sends the copy of exisiting router-lsa in its >>db >>description packet >>5. R2 already has this copy and therefore does not >>request for it (Sec13.1 rfc 2328) >>6. After minLSInterval, R1 re-originates its router >>lsa >>7. R2 assumes it to be the same as its existing copy >>(sec 13.2) and does not run its SPF. >> >>This might cause an inconsistent routing table on >>R2. >>What am I missing in the above sequence? >> >>Thanks >>John >> >> >> >>__________________________________ >>Do you Yahoo!? >>Yahoo! Mail - Find what you need with new enhanced >>search. >>http://info.mail.yahoo.com/mail_250 >> >> >> >> >> >> >*************************************************************************** > > >>This message is proprietary to Future Software >>Limited (FSL) >>and is intended solely for the use of the individual >>to whom it >>is addressed. It may contain privileged or >>confidential information >>and should not be circulated or used for any purpose >>other than for >>what it is intended. >> >>If you have received this message in error, please >>notify the >>originator immediately. If you are not the intended >>recipient, >>you are notified that you are strictly prohibited >>from using, >>copying, altering, or disclosing the contents of >>this message. >>FSL accepts no responsibility for loss or damage >>arising from >>the use of the information transmitted by this email >>including >>damage from virus. >> >> >> >*************************************************************************** > > > > >__________________________________________________ >Do You Yahoo!? >Tired of spam? Yahoo! Mail has the best spam protection around >http://mail.yahoo.com > > > From owner-ospf@PEACH.EASE.LSOFT.COM Mon Jan 31 12:08:31 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24247 for ; Mon, 31 Jan 2005 12:08:31 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00F6545D@cherry.ease.lsoft.com>; Mon, 31 Jan 2005 12:08:31 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 55881722 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 31 Jan 2005 12:08:29 -0500 Received: from 203.197.138.222 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 31 Jan 2005 12:08:28 -0500 Received: from kailash.future.futsoft.com (unverified [203.197.140.36]) by mail1.future.futsoft.com (Content Technologies SMTPRS 4.3.12) with ESMTP id for ; Mon, 31 Jan 2005 22:38:48 +0530 Received: from manishgs (manishgs.future.futsoft.com [10.203.113.5]) by kailash.future.futsoft.com (8.12.8/8.12.8) with SMTP id j0VH635q022532 for ; Mon, 31 Jan 2005 22:36:04 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: <000701c5055c$6912d860$0571cb0a@future.futsoft.com> Date: Fri, 28 Jan 2005 22:41:29 +0530 Reply-To: Mailing List Sender: Mailing List From: Manish Gupta Subject: Re: OSPFv2 db-exchange To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <41FE3075.8080005@cisco.com> Precedence: list Content-Transfer-Encoding: 7bit Hi Acee, please see inline -----Original Message----- From: Mailing List [mailto:OSPF@peach.ease.lsoft.com]On Behalf Of Acee Lindem Sent: Monday, 31 January 2005 6:50 PM To: OSPF@peach.ease.lsoft.com Subject: Re: OSPFv2 db-exchange Hi John, Now I think I understand your scenario - see inline. John Pecola wrote: >Manish, > >R2 may also go through similar sequence that R1 went >through. When the adjacency went down, R2 was unable >to re-originate its router LSA because of >minLSInterval. When it eventually does, adjacency is >already back up, does it mean that adjacency with R1 is become FULL when R2 re-originate router LSA after MinLSInterval ? (i am asumming it's FULL) and so R2 should see its router lsa >unchanged (Sec 13.2) and not re-install it R2 must install the LSA since it is more recent (sequence number will increament). but it need not to run the SPF. > In any case, it should re-install it in the database since it is more recent. > (and not >run its routing table calculation). Is this assumption >correct? i think this is o.k It need not re-run the routing calculation if the LSA is unchanged. However, it will definitely re-run it's routing calculation when it goes to FULL state with R1. i think the state is already FULL and there is no need to run the SPF in this situation. even if you run the SPF the routing table will be same only. Regards Manish Gupta >Thanks >John > >--- Manish Gupta wrote: > > > >>Hi Joan, >> >>SPF needs to be run whenever router received a new >>LSA via flooding OR >>it's newly self-originated LSA installed in >>database. >>in your case due to MinLsaInterval you have not >>received router LSA from R1. >>but when adjacency goes down, R2 will generate a new >>instance of Router LSA >>in which Point-to-point link (link type 1, and Link >>Id as R1 router ID) >>should not be there by which R2 will know that >>R1 is nor reachable and it can calculate the correct >>routes. >>and when the adjacency become FULL R2 will again >>generate the router LSA >>with point-to-point link (link type 1, and Link Id >>as R1 router ID) by which >>it can caculate the correct routes. >> >>Regards >>Manish Gupta >> >> >>-----Original Message----- >>From: Mailing List >>[mailto:OSPF@peach.ease.lsoft.com]On Behalf Of John >>Pecola >>Sent: Saturday, 29 January 2005 10:49 AM >>To: OSPF@peach.ease.lsoft.com >>Subject: OSPFv2 db-exchange >> >> >>In this setup (OSPFv2), following sequence of events >>take place - >> >> R1--------Pt-to-Pt-------R2 >> >>1. Adjacency between R1 and R2 goes down >>2. R1 postpones re-origination of its router lsa >>because it did so less than minLSInterval before >>3. R1 and R2 go into exchange state >>4. R1 sends the copy of exisiting router-lsa in its >>db >>description packet >>5. R2 already has this copy and therefore does not >>request for it (Sec13.1 rfc 2328) >>6. After minLSInterval, R1 re-originates its router >>lsa >>7. R2 assumes it to be the same as its existing copy >>(sec 13.2) and does not run its SPF. >> >>This might cause an inconsistent routing table on >>R2. >>What am I missing in the above sequence? >> >>Thanks >>John >> >> >> >>__________________________________ >>Do you Yahoo!? >>Yahoo! Mail - Find what you need with new enhanced >>search. >>http://info.mail.yahoo.com/mail_250 >> >> >> >> >> >> >*************************************************************************** > > >>This message is proprietary to Future Software >>Limited (FSL) >>and is intended solely for the use of the individual >>to whom it >>is addressed. It may contain privileged or >>confidential information >>and should not be circulated or used for any purpose >>other than for >>what it is intended. >> >>If you have received this message in error, please >>notify the >>originator immediately. If you are not the intended >>recipient, >>you are notified that you are strictly prohibited >>from using, >>copying, altering, or disclosing the contents of >>this message. >>FSL accepts no responsibility for loss or damage >>arising from >>the use of the information transmitted by this email >>including >>damage from virus. >> >> >> >*************************************************************************** > > > > >__________________________________________________ >Do You Yahoo!? >Tired of spam? Yahoo! Mail has the best spam protection around >http://mail.yahoo.com > > > *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** From owner-ospf@PEACH.EASE.LSOFT.COM Mon Jan 31 13:24:57 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03195 for ; Mon, 31 Jan 2005 13:24:55 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.00F656D2@cherry.ease.lsoft.com>; Mon, 31 Jan 2005 13:24:52 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 55889830 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 31 Jan 2005 13:24:50 -0500 Received: from 64.102.122.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 31 Jan 2005 13:24:50 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 31 Jan 2005 13:24:50 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j0VIOmW0002452 for ; Mon, 31 Jan 2005 13:24:48 -0500 (EST) Received: from [10.82.217.100] (rtp-vpn3-354.cisco.com [10.82.217.100]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BEY77456; Mon, 31 Jan 2005 10:24:45 -0800 (PST) User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <000701c5055c$6912d860$0571cb0a@future.futsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <41FE77ED.2010309@cisco.com> Date: Mon, 31 Jan 2005 13:24:45 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: OSPFv2 db-exchange To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <000701c5055c$6912d860$0571cb0a@future.futsoft.com> Precedence: list Content-Transfer-Encoding: 7bit Manish Gupta wrote: >Hi Acee, > >please see inline > >-----Original Message----- >From: Mailing List [mailto:OSPF@peach.ease.lsoft.com]On Behalf Of Acee >Lindem >Sent: Monday, 31 January 2005 6:50 PM >To: OSPF@peach.ease.lsoft.com >Subject: Re: OSPFv2 db-exchange > > >Hi John, > >Now I think I understand your scenario - see inline. > >John Pecola wrote: > > > >>Manish, >> >>R2 may also go through similar sequence that R1 went >>through. When the adjacency went down, R2 was unable >>to re-originate its router LSA because of >>minLSInterval. When it eventually does, adjacency is >>already back up, >> >> > > does it mean that adjacency with R1 is become FULL when R2 >re-originate router LSA after MinLSInterval ? > (i am asumming it's FULL) > Both sides can't become full until they have left LOADING state and consequently received all more recent LSAs from each other (including their own originations due to the adjacency flapping). Hence, I don't think this is a possible situation. >and so R2 should see its router lsa > > >>unchanged (Sec 13.2) and not re-install it >> >> > > R2 must install the LSA since it is more recent (sequence number >will increament). > but it need not to run the SPF. > > >In any case, it should re-install it in the database since it is more >recent. > > > >>(and not >>run its routing table calculation). Is this assumption >>correct? >> >> > > i think this is o.k > >It need not re-run the routing calculation if the LSA is unchanged. >However, it will >definitely re-run it's routing calculation when it goes to FULL state >with R1. > > i think the state is already FULL and there is no need to run the >SPF in this situation. > even if you run the SPF the routing table will be same only. > > >Regards >Manish Gupta > > > > > >>Thanks >>John >> >>--- Manish Gupta wrote: >> >> >> >> >> >>>Hi Joan, >>> >>>SPF needs to be run whenever router received a new >>>LSA via flooding OR >>>it's newly self-originated LSA installed in >>>database. >>>in your case due to MinLsaInterval you have not >>>received router LSA from R1. >>>but when adjacency goes down, R2 will generate a new >>>instance of Router LSA >>>in which Point-to-point link (link type 1, and Link >>>Id as R1 router ID) >>>should not be there by which R2 will know that >>>R1 is nor reachable and it can calculate the correct >>>routes. >>>and when the adjacency become FULL R2 will again >>>generate the router LSA >>>with point-to-point link (link type 1, and Link Id >>>as R1 router ID) by which >>>it can caculate the correct routes. >>> >>>Regards >>>Manish Gupta >>> >>> >>>-----Original Message----- >>>From: Mailing List >>>[mailto:OSPF@peach.ease.lsoft.com]On Behalf Of John >>>Pecola >>>Sent: Saturday, 29 January 2005 10:49 AM >>>To: OSPF@peach.ease.lsoft.com >>>Subject: OSPFv2 db-exchange >>> >>> >>>In this setup (OSPFv2), following sequence of events >>>take place - >>> >>> R1--------Pt-to-Pt-------R2 >>> >>>1. Adjacency between R1 and R2 goes down >>>2. R1 postpones re-origination of its router lsa >>>because it did so less than minLSInterval before >>>3. R1 and R2 go into exchange state >>>4. R1 sends the copy of exisiting router-lsa in its >>>db >>>description packet >>>5. R2 already has this copy and therefore does not >>>request for it (Sec13.1 rfc 2328) >>>6. After minLSInterval, R1 re-originates its router >>>lsa >>>7. R2 assumes it to be the same as its existing copy >>>(sec 13.2) and does not run its SPF. >>> >>>This might cause an inconsistent routing table on >>>R2. >>>What am I missing in the above sequence? >>> >>>Thanks >>>John >>> >>> >>> >>>__________________________________ >>>Do you Yahoo!? >>>Yahoo! Mail - Find what you need with new enhanced >>>search. >>>http://info.mail.yahoo.com/mail_250 >>> >>> >>> >>> >>> >>> >>> >>> >>*************************************************************************** >> >> >> >> >>>This message is proprietary to Future Software >>>Limited (FSL) >>>and is intended solely for the use of the individual >>>to whom it >>>is addressed. It may contain privileged or >>>confidential information >>>and should not be circulated or used for any purpose >>>other than for >>>what it is intended. >>> >>>If you have received this message in error, please >>>notify the >>>originator immediately. If you are not the intended >>>recipient, >>>you are notified that you are strictly prohibited >>> >>> >>>from using, >> >> >>>copying, altering, or disclosing the contents of >>>this message. >>>FSL accepts no responsibility for loss or damage >>>arising from >>>the use of the information transmitted by this email >>>including >>>damage from virus. >>> >>> >>> >>> >>> >>*************************************************************************** >> >> >> >> >>__________________________________________________ >>Do You Yahoo!? >>Tired of spam? Yahoo! Mail has the best spam protection around >>http://mail.yahoo.com >> >> >> >> >> > > > >*************************************************************************** >This message is proprietary to Future Software Limited (FSL) >and is intended solely for the use of the individual to whom it >is addressed. It may contain privileged or confidential information >and should not be circulated or used for any purpose other than for >what it is intended. > >If you have received this message in error, please notify the >originator immediately. If you are not the intended recipient, >you are notified that you are strictly prohibited from using, >copying, altering, or disclosing the contents of this message. >FSL accepts no responsibility for loss or damage arising from >the use of the information transmitted by this email including >damage from virus. >*************************************************************************** > > >