From owner-ospf@PEACH.EASE.LSOFT.COM Fri Apr 1 15:37: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 PAA09122 for ; Fri, 1 Apr 2005 15:37: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 <11.00FFAD07@cherry.ease.lsoft.com>; Fri, 1 Apr 2005 15:37:14 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 64917752 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 1 Apr 2005 15:37:11 -0500 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 1 Apr 2005 15:26:45 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06152; Fri, 1 Apr 2005 15:26:40 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200504012026.PAA06152@ietf.org> Date: Fri, 1 Apr 2005 15:26:40 -0500 Reply-To: Mailing List Sender: Mailing List From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ospf-iana-00.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 : IANA Considerations for OSPF Author(s) : K. Kompella Filename : draft-ietf-ospf-iana-00.txt Pages : 14 Date : 2005-4-1 This memo creates a number of OSPF registries and provides guidance to IANA for assignment of code points within these registries. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-iana-00.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-iana-00.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-iana-00.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-4-1155118.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ospf-iana-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ospf-iana-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-4-1155118.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@PEACH.EASE.LSOFT.COM Mon Apr 4 12:51: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 MAA27451 for ; Mon, 4 Apr 2005 12:51:45 -0400 (EDT) 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.01000189@cherry.ease.lsoft.com>; Mon, 4 Apr 2005 12:51:40 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 65271668 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 4 Apr 2005 12:51:36 -0400 Received: from 62.241.163.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 4 Apr 2005 12:51:36 -0500 Received: from pc6 (1Cust108.tnt30.lnd3.gbr.da.uu.net [62.188.122.108]) by astro.systems.pipex.net (Postfix) with SMTP id 4D64DE0000AE for ; Mon, 4 Apr 2005 17:51:34 +0100 (BST) 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.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-ID: <00af01c5392d$ba757aa0$0601a8c0@pc6> Date: Mon, 4 Apr 2005 17:46:09 +0200 Reply-To: Mailing List Sender: Mailing List From: Tom Petch Subject: draft-ietf-ospf-iana-00 To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit I am curious about the choice of four octet for enterprise code in 2.5. When used in SNMP, these codes have no effective limit on length; four octet does seem massive compared to current use (just like the four octet limit of IP address did a few years ago:-) I wonder if it is worth a comment in the I-D that this is imposing a limit not present in the IANA registratoin, albeit one that hopefully will last some time. Tom Petch From owner-ospf@PEACH.EASE.LSOFT.COM Mon Apr 4 17:58:27 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 RAA16443 for ; Mon, 4 Apr 2005 17:58:27 -0400 (EDT) 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.0100115E@cherry.ease.lsoft.com>; Mon, 4 Apr 2005 17:58:27 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 65301764 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 4 Apr 2005 17:58:23 -0400 Received: from 64.102.122.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 4 Apr 2005 17:58:23 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 04 Apr 2005 17:58:23 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j34LwKjI024334 for ; Mon, 4 Apr 2005 17:58:21 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 4 Apr 2005 17:58:06 -0400 Received: from [10.82.225.186] ([10.82.225.186]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 4 Apr 2005 17:59:38 -0400 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 X-OriginalArrivalTime: 04 Apr 2005 21:59:38.0664 (UTC) FILETIME=[98B69280:01C53961] Message-ID: <4251B87B.6020905@cisco.com> Date: Mon, 4 Apr 2005 17:58:19 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Enforcement of Updated IPR Boilerplate To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit FYI. A new release of xml2rfc will soon be available that supports "full3978" (as well as some other 3978 variants) in the for the ipr keyword in the tag. -------- Original Message -------- Subject: Enforcement of Updated IPR Boilerplate Date: Mon, 04 Apr 2005 13:05:48 -0400 From: IETF Secretariat To: IETF Announcement list CC: wgchairs@ietf.org, chair@ietf.org As you may be aware, RFC 3667 (BCP 78), "IETF Rights in Contributions," has been obsoleted by RFC 3978 (BCP 78), which was published in March 2005, and which bears the same title. The major difference between the two RFCs is that the IPR-related notices and disclaimers that the IETF requires in all Internet-Drafts have been updated to correct anomalies. The updated versions of the required notices and disclaimers are specified in Section 5, "Notices Required in IETF Documents," of RFC 3978, and in Section 3, "IPR-Related Notices Required in Internet-Drafts," of the recently revised "Guidelines to Authors of Internet-Drafts" (http://www.ietf.org/ietf/1id-guidelines.html). The "Guidelines" document also provides additional guidance regarding the placement of these notices. Currently, the IETF Secretariat accepts and posts Internet-Drafts that include *either* the RFC 3667 or the RFC 3978 version of these notices. However, as of 17:00 ET on Friday May 6, 2005, the Secretariat will accept *only* those Internet-Drafts that comply with the requirements of RFC 3978, and with the most recent version of the "Guidelines" document. Please note that the required notices and disclaimers must be reproduced verbatim since they have been legally reviewed and formally adopted as part of the IETF process. The Secretariat will not accept deviations from the specified text, nor will it correct the text. Any documents that do not comply with the requirements will be returned to the submitter. The IETF Secretariat From owner-ospf@PEACH.EASE.LSOFT.COM Mon Apr 4 18:07:59 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 SAA17609 for ; Mon, 4 Apr 2005 18:07:58 -0400 (EDT) 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.0100122C@cherry.ease.lsoft.com>; Mon, 4 Apr 2005 18:07:59 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 65302964 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 4 Apr 2005 18:07:58 -0400 Received: from 66.129.224.36 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 4 Apr 2005 18:07:57 -0500 Received: from kummer.juniper.net (localhost [127.0.0.1]) by kummer.juniper.net (8.12.8p1/8.12.3) with ESMTP id j34M7uXg002340 for ; Mon, 4 Apr 2005 15:07:56 -0700 (PDT) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.12.8p1/8.12.3/Submit) with ESMTP id j34M7uSc002337 for ; Mon, 4 Apr 2005 15:07:56 -0700 (PDT) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs References: <00af01c5392d$ba757aa0$0601a8c0@pc6> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: <20050404145631.L706@kummer.juniper.net> Date: Mon, 4 Apr 2005 15:07:56 -0700 Reply-To: Mailing List Sender: Mailing List From: Kireeti Kompella Subject: Re: draft-ietf-ospf-iana-00 To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <00af01c5392d$ba757aa0$0601a8c0@pc6> Precedence: list On Mon, 4 Apr 2005, Tom Petch wrote: > I am curious about the choice of four octet for enterprise code in 2.5. > > When used in SNMP, these codes have no effective limit on length; I was under the impression that each number in an OID sequence was a 32-bit number. Is that not right? If so, the first enterprise with an enterprise ID >= 2^32 would have more serious problems than not being able to use OSPF Private Use spaces, assuming SNMP is still around at that time. > four octet does seem massive compared to current use (just like the > four octet limit of IP address did a few years ago:-) The first two billion (or four billion) enterprises will be able to use the Private Space; the rest ... well, too bad. Hmmm. I wonder if IANA will give me a /8 chunk of enterprise number space ... > I wonder if it is worth a comment in the I-D that this is imposing a > limit not present in the IANA registratoin, albeit one that > hopefully will last some time. I'm not against that, although the answer above may address this. On the other hand, if an OID can only take four octet numbers, either IANA or RFC 2578 should state the issues that enterprises with numbers >= 2^32 will face. Kireeti. ------- From owner-ospf@PEACH.EASE.LSOFT.COM Mon Apr 4 18:42: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 SAA20926 for ; Mon, 4 Apr 2005 18:42:32 -0400 (EDT) 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.01001212@cherry.ease.lsoft.com>; Mon, 4 Apr 2005 18:42:23 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 65306189 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 4 Apr 2005 18:42:20 -0400 Received: from 64.102.122.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 4 Apr 2005 18:42:20 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 04 Apr 2005 19:03:19 -0400 X-IronPort-AV: i="3.91,148,1110171600"; d="scan'208"; a="43126417:sNHT6554936024" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j34MgD1l025646 for ; Mon, 4 Apr 2005 18:42:16 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 4 Apr 2005 18:42:00 -0400 Received: from [10.82.225.186] ([10.82.225.186]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 4 Apr 2005 18:42:14 -0400 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 X-OriginalArrivalTime: 04 Apr 2005 22:42:14.0439 (UTC) FILETIME=[8C12E370:01C53967] Message-ID: <4251C2C5.8000608@cisco.com> Date: Mon, 4 Apr 2005 18:42:13 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Working Group Last Call on "Multi-Topology (MT) Routing in OSPF" (draft-ietf-ospf-mt-03.txt) To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit This is the start of a Working Group last call for "Multi-Topology (MT) Routing in OSPF" (draft-ietf-ospf-mt-03.txt). All comments should be sent to this list by 12 AM (EDT), 04/19/2005. The draft can be found at http://www.ietf.org/internet-drafts/draft-ietf-ospf-scalability-06.txt A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-mt-03.txt The RFC 3978 IPR notices will be updated in the next revision. Thanks, Acee From owner-ospf@PEACH.EASE.LSOFT.COM Mon Apr 4 18:45:50 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 SAA21216 for ; Mon, 4 Apr 2005 18:45:49 -0400 (EDT) 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.01001474@cherry.ease.lsoft.com>; Mon, 4 Apr 2005 18:45:50 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 65306553 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 4 Apr 2005 18:45:49 -0400 Received: from 64.102.122.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 4 Apr 2005 18:45:49 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 04 Apr 2005 18:45:50 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j34MjkjI004578 for ; Mon, 4 Apr 2005 18:45:47 -0400 (EDT) Received: from xfe-rtp-212.amer.cisco.com ([64.102.31.100]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 4 Apr 2005 18:45:32 -0400 Received: from [10.82.225.186] ([10.82.225.186]) by xfe-rtp-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 4 Apr 2005 18:45:23 -0400 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 X-OriginalArrivalTime: 04 Apr 2005 22:45:23.0951 (UTC) FILETIME=[FD081FF0:01C53967] Message-ID: <4251C399.8030906@cisco.com> Date: Mon, 4 Apr 2005 18:45:45 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Working Group Last Call on "Multi-Topology (MT) Routing in OSPF" (draft-ietf-ospf-mt-03.txt) - Corrected To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit This is the start of a Working Group last call for "Multi-Topology (MT) Routing in OSPF" (draft-ietf-ospf-mt-03.txt). All comments should be sent to this list by 12 AM (EDT), 04/19/2005. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-mt-03.txt The RFC 3978 IPR notices will be updated in the next revision. Thanks, Acee From owner-ospf@PEACH.EASE.LSOFT.COM Tue Apr 5 13:36:05 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 NAA11487 for ; Tue, 5 Apr 2005 13:36:05 -0400 (EDT) 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.010031C9@cherry.ease.lsoft.com>; Tue, 5 Apr 2005 13:36:01 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 65415403 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 5 Apr 2005 13:36:00 -0400 Received: from 207.17.137.57 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 5 Apr 2005 13:36:00 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id j35HZx925387 for ; Tue, 5 Apr 2005 10:35:59 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j35HZre49565; Tue, 5 Apr 2005 10:35:53 -0700 (PDT) (envelope-from yakov@juniper.net) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <50435.1112722553.1@juniper.net> Message-ID: <200504051735.j35HZre49565@merlot.juniper.net> Date: Tue, 5 Apr 2005 10:35:53 -0700 Reply-To: Mailing List Sender: Mailing List From: Yakov Rekhter Subject: Re: Working Group Last Call on "Multi-Topology (MT) Routing in OSPF" (draft-ietf-ospf-mt-03.txt) - Corrected To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Your message of "Mon, 04 Apr 2005 18:45:45 EDT." <4251C399.8030906@cisco.com> Precedence: list Folks, > This is the start of a Working Group last call for > "Multi-Topology (MT) Routing in OSPF" (draft-ietf-ospf-mt-03.txt). > All comments should be sent to this list by 12 AM (EDT), 04/19/2005. How is computing different paths for different classes of service mention in the draft differs from ToS routing ? Yakov. From owner-ospf@PEACH.EASE.LSOFT.COM Tue Apr 5 15:10: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 PAA20271 for ; Tue, 5 Apr 2005 15:10:07 -0400 (EDT) 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.01003566@cherry.ease.lsoft.com>; Tue, 5 Apr 2005 15:10:07 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 65423804 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 5 Apr 2005 15:10:04 -0400 Received: from 62.241.162.31 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 5 Apr 2005 15:10:04 -0500 Received: from pc6 (1Cust107.tnt7.lnd4.gbr.da.uu.net [62.188.136.107]) by galaxy.systems.pipex.net (Postfix) with SMTP id 01798E0002AC for ; Tue, 5 Apr 2005 20:10:02 +0100 (BST) References: <00af01c5392d$ba757aa0$0601a8c0@pc6> <20050404145631.L706@kummer.juniper.net> 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.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-ID: <019701c53a0a$3b66bd40$0601a8c0@pc6> Date: Tue, 5 Apr 2005 20:06:16 +0200 Reply-To: Mailing List Sender: Mailing List From: Tom Petch Subject: Re: draft-ietf-ospf-iana-00 To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Tom Petch ----- Original Message ----- From: "Kireeti Kompella" To: Sent: Tuesday, April 05, 2005 12:07 AM Subject: Re: draft-ietf-ospf-iana-00 > On Mon, 4 Apr 2005, Tom Petch wrote: > > > I am curious about the choice of four octet for enterprise code in 2.5. > > > > When used in SNMP, these codes have no effective limit on length; > > I was under the impression that each number in an OID sequence was a > 32-bit number. Is that not right? Not so. BER.1 encodes the sub-identifiers of an OID (after the first two) in what I think of as CCITT encoding, using 7 bits per octet with the other bit as a flag to say this is (or is not) the last octet. So a 7 bit sub-identifier encodes in one octet, 14 bit in two and so on. I have never seen any other limit imposed and - knowing ISO - I would not expect there to be one (apart from the overall limit on length of a TLV which is 2**1008 octet - this is ISO:-). From owner-ospf@PEACH.EASE.LSOFT.COM Tue Apr 5 17:24: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 RAA18584 for ; Tue, 5 Apr 2005 17:24:21 -0400 (EDT) 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.0100389D@cherry.ease.lsoft.com>; Tue, 5 Apr 2005 17:24:19 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 65434326 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 5 Apr 2005 17:24:18 -0400 Received: from 66.129.224.36 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 5 Apr 2005 17:23:38 -0500 Received: from kummer.juniper.net (localhost [127.0.0.1]) by kummer.juniper.net (8.12.8p1/8.12.3) with ESMTP id j35LNbXg006989 for ; Tue, 5 Apr 2005 14:23:37 -0700 (PDT) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.12.8p1/8.12.3/Submit) with ESMTP id j35LNbLr006986 for ; Tue, 5 Apr 2005 14:23:37 -0700 (PDT) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs References: <00af01c5392d$ba757aa0$0601a8c0@pc6> <20050404145631.L706@kummer.juniper.net> <019701c53a0a$3b66bd40$0601a8c0@pc6> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: <20050405141805.T5370@kummer.juniper.net> Date: Tue, 5 Apr 2005 14:23:37 -0700 Reply-To: Mailing List Sender: Mailing List From: Kireeti Kompella Subject: Re: draft-ietf-ospf-iana-00 To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <019701c53a0a$3b66bd40$0601a8c0@pc6> Precedence: list On Tue, 5 Apr 2005, Tom Petch wrote: > > I was under the impression that each number in an OID sequence was a > > 32-bit number. Is that not right? > > Not so. BER.1 encodes the sub-identifiers of an OID (after the > first two) in what I think of as CCITT encoding, using 7 bits per > octet with the other bit as a flag to say this is (or is not) the > last octet. So a 7 bit sub-identifier encodes in one octet, 14 bit > in two and so on. Yeesh! Thanks for the info -- I would never have guessed. > I have never seen any other limit imposed and - knowing ISO - I Oh, well. Does anyone care? Where were you when I wrote what became RFC 3936 (see section 2, para 3)? > would not expect there to be one (apart from the overall limit on > length of a TLV which is 2**1008 octet - this is ISO:-). If every atom could encode one octet, how many galaxies would that be? :-) Kireeti. ------- From owner-ospf@PEACH.EASE.LSOFT.COM Tue Apr 5 17:48: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 RAA21292 for ; Tue, 5 Apr 2005 17:48:06 -0400 (EDT) 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.010038EF@cherry.ease.lsoft.com>; Tue, 5 Apr 2005 17:48:06 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 65435599 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 5 Apr 2005 17:48:05 -0400 Received: from 144.254.15.118 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 5 Apr 2005 17:48:05 -0500 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j35Lm4T01973 for ; Tue, 5 Apr 2005 23:48:04 +0200 (CEST) Received: from cisco.com (dhcp-128-107-178-183.cisco.com [128.107.178.183]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j35Lm3K00486 for ; Tue, 5 Apr 2005 23:48:03 +0200 (CEST) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <200504051735.j35HZre49565@merlot.juniper.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <42530792.6030805@cisco.com> Date: Tue, 5 Apr 2005 14:48:02 -0700 Reply-To: Mailing List Sender: Mailing List From: Peter Psenak Subject: Re: Working Group Last Call on "Multi-Topology (MT) Routing in OSPF" (draft-ietf-ospf-mt-03.txt) - Corrected To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Yakov, Yakov Rekhter wrote: > Folks, > > >>This is the start of a Working Group last call for >>"Multi-Topology (MT) Routing in OSPF" (draft-ietf-ospf-mt-03.txt). >>All comments should be sent to this list by 12 AM (EDT), 04/19/2005. > > > How is computing different paths for different classes of service > mention in the draft differs from ToS routing ? one difference compared to ToS routing as specified in 1583 is the ability to include/exclude each link/prefix in/from each topology. Peter > > Yakov. > From owner-ospf@PEACH.EASE.LSOFT.COM Tue Apr 5 23:11: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 XAA16669 for ; Tue, 5 Apr 2005 23:11:58 -0400 (EDT) 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.010040BD@cherry.ease.lsoft.com>; Tue, 5 Apr 2005 23:11:57 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 65455843 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 5 Apr 2005 23:11:56 -0400 Received: from 64.102.122.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 5 Apr 2005 23:11:54 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 05 Apr 2005 23:11:54 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j363Bp1j007876 for ; Tue, 5 Apr 2005 23:11:52 -0400 (EDT) Received: from xfe-rtp-212.amer.cisco.com ([64.102.31.100]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 5 Apr 2005 23:11:51 -0400 Received: from [10.82.242.168] ([10.82.242.168]) by xfe-rtp-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 5 Apr 2005 23:11:51 -0400 User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <200504051735.j35HZre49565@merlot.juniper.net> <42530792.6030805@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Apr 2005 03:11:51.0099 (UTC) FILETIME=[608710B0:01C53A56] Message-ID: <42535376.8010105@cisco.com> Date: Tue, 5 Apr 2005 23:11:50 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Working Group Last Call on "Multi-Topology (MT) Routing in OSPF" (draft-ietf-ospf-mt-03.txt) - Corrected To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <42530792.6030805@cisco.com> Precedence: list Content-Transfer-Encoding: 7bit Note that this is a standards track draft. I neglected to mention this in the original WG last call announcement. There are, at least, two other subtle differences with RFC 1583 TOS routing: 1. With RFC 1583 TOS routing the TOS or DSCP in the IP header mapping directly to the the corresponding OSPF SPF and RIB. With multi-topology routing, the classification of what type of traffic maps to which topology is not within the scope of the document (other than the default unicast and default multicast topologies are reserved). There are appropriate warnings that all routers in the OSPF routing domain should classify traffic consistently. 2. With RFC 1583 TOS routing, traffic which is unreachable in the RIB associated with the corresponding TOS will revert to the TOS 0 RIB. With multi-topology routing, this is an option but not required. Of course, all routers in the OSPF routing domain should make this decision consistently. Thanks, Acee Peter Psenak wrote: > Yakov, > > Yakov Rekhter wrote: > >> Folks, >> >> >>> This is the start of a Working Group last call for >>> "Multi-Topology (MT) Routing in OSPF" (draft-ietf-ospf-mt-03.txt). >>> All comments should be sent to this list by 12 AM (EDT), 04/19/2005. >> >> >> >> How is computing different paths for different classes of service >> mention in the draft differs from ToS routing ? > > > one difference compared to ToS routing as specified in 1583 is the > ability to include/exclude each link/prefix in/from each topology. > > Peter > >> >> Yakov. >> > From owner-ospf@PEACH.EASE.LSOFT.COM Tue Apr 5 23:21: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 XAA17376 for ; Tue, 5 Apr 2005 23:21:41 -0400 (EDT) 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.01004182@cherry.ease.lsoft.com>; Tue, 5 Apr 2005 23:21:41 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 65455832 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 5 Apr 2005 23:21:40 -0400 Received: from 156.153.255.245 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 5 Apr 2005 23:11:40 -0500 Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.43.209.160]) by palrel10.hp.com (Postfix) with ESMTP id 63A7C6A3 for ; Tue, 5 Apr 2005 20:11:39 -0700 (PDT) Received: from [127.0.0.1] (ros54018lap.americas.hpqcorp.net [15.255.5.21]) by rosemail.rose.hp.com (Postfix) with ESMTP id 60C637FF2 for ; Tue, 5 Apr 2005 20:11:39 -0700 (PDT) User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <00af01c5392d$ba757aa0$0601a8c0@pc6> <20050404145631.L706@kummer.juniper.net> <019701c53a0a$3b66bd40$0601a8c0@pc6> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <425351AB.4040308@hp.com> Date: Tue, 5 Apr 2005 20:04:11 -0700 Reply-To: Mailing List Sender: Mailing List From: John Flick Subject: Re: draft-ietf-ospf-iana-00 To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <019701c53a0a$3b66bd40$0601a8c0@pc6> Precedence: list Content-Transfer-Encoding: 7bit Actually, this information is true for ISO ASN.1, but not for SNMP. SNMP's SMI is an "adapted subset" of ASN.1. That subset is defined in RFCs 2578-2580. From RFC 2578, section 3.5: An OBJECT IDENTIFIER value is an ordered list of non-negative numbers. For the SMIv2, each number in the list is referred to as a sub-identifier, there are at most 128 sub-identifiers in a value, and each sub-identifier has a maximum value of 232-1 (4294967295 decimal). I don't believe we have run into any problems with these limits in SNMP :-) . So, I don't believe that draft-ietf-ospf-iana draft has a problem here. John Tom Petch wrote: > > Tom Petch > ----- Original Message ----- > From: "Kireeti Kompella" > To: > Sent: Tuesday, April 05, 2005 12:07 AM > Subject: Re: draft-ietf-ospf-iana-00 > > > >>On Mon, 4 Apr 2005, Tom Petch wrote: >> >> >>>I am curious about the choice of four octet for enterprise code in 2.5. >>> >>>When used in SNMP, these codes have no effective limit on length; >> >>I was under the impression that each number in an OID sequence was a >>32-bit number. Is that not right? > > > Not so. BER.1 encodes the sub-identifiers of an OID (after the first two) in > what I think of as CCITT encoding, using 7 bits per octet with the other bit as > a flag to say this is (or is not) the last octet. So a 7 bit sub-identifier > encodes in one octet, 14 bit in two and so on. > > I have never seen any other limit imposed and - knowing ISO - I would not expect > there to be one (apart from the overall limit on length of a TLV which is > 2**1008 octet - this is ISO:-). > > > From owner-ospf@PEACH.EASE.LSOFT.COM Wed Apr 6 09:34:27 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 JAA11080 for ; Wed, 6 Apr 2005 09:34:26 -0400 (EDT) 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.01004AE8@cherry.ease.lsoft.com>; Wed, 6 Apr 2005 9:34:26 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 65484632 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 6 Apr 2005 09:34:25 -0400 Received: from 207.17.137.57 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 6 Apr 2005 09:34:24 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id j36DYN933502 for ; Wed, 6 Apr 2005 06:34:24 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j36DYIe65964; Wed, 6 Apr 2005 06:34:18 -0700 (PDT) (envelope-from yakov@juniper.net) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <88185.1112794458.1@juniper.net> Message-ID: <200504061334.j36DYIe65964@merlot.juniper.net> Date: Wed, 6 Apr 2005 06:34:18 -0700 Reply-To: Mailing List Sender: Mailing List From: Yakov Rekhter Subject: Re: Working Group Last Call on "Multi-Topology (MT) Routing in OSPF" (draft-ietf-ospf-mt-03.txt) - Corrected To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Your message of "Mon, 04 Apr 2005 18:45:45 EDT." <4251C399.8030906@cisco.com> Precedence: list Folks, > This is the start of a Working Group last call for > "Multi-Topology (MT) Routing in OSPF" (draft-ietf-ospf-mt-03.txt). > All comments should be sent to this list by 12 AM (EDT), 04/19/2005. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ospf-mt-03.txt > > The RFC 3978 IPR notices will be updated in the next revision. As the draft correctly points out: TOS based routing as described in [RFC1583] was never deployed and was subsequently deprecated. So, why computing different paths for different classes of service be any different ? Yakov. From owner-ospf@PEACH.EASE.LSOFT.COM Wed Apr 6 12:08: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 MAA00028 for ; Wed, 6 Apr 2005 12:08:32 -0400 (EDT) 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.01004FB0@cherry.ease.lsoft.com>; Wed, 6 Apr 2005 12:08:33 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 65504001 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 6 Apr 2005 12:08:32 -0400 Received: from 144.254.15.118 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 6 Apr 2005 12:08:31 -0500 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j36G8Ub15683 for ; Wed, 6 Apr 2005 18:08:30 +0200 (CEST) Received: from cisco.com (dhcp-128-107-178-183.cisco.com [128.107.178.183]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j36G8TK02033 for ; Wed, 6 Apr 2005 18:08:29 +0200 (CEST) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <200504061334.j36DYIe65964@merlot.juniper.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <4254097C.9020901@cisco.com> Date: Wed, 6 Apr 2005 09:08:28 -0700 Reply-To: Mailing List Sender: Mailing List From: Peter Psenak Subject: Re: Working Group Last Call on "Multi-Topology (MT) Routing in OSPF" (draft-ietf-ospf-mt-03.txt) - Corrected To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Yakov, Yakov Rekhter wrote: > Folks, > > >>This is the start of a Working Group last call for >>"Multi-Topology (MT) Routing in OSPF" (draft-ietf-ospf-mt-03.txt). >>All comments should be sent to this list by 12 AM (EDT), 04/19/2005. >> >>A URL for this Internet-Draft is: >>http://www.ietf.org/internet-drafts/draft-ietf-ospf-mt-03.txt >> >>The RFC 3978 IPR notices will be updated in the next revision. > > > As the draft correctly points out: > > TOS based routing as described in [RFC1583] was never > deployed and was subsequently deprecated. > > So, why computing different paths for different classes of service > be any different ? because MTR allows people to do things that were not possible with the TOS based routing as described in [RFC1583]. Peter > > Yakov. > From owner-ospf@PEACH.EASE.LSOFT.COM Wed Apr 6 12:30: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 MAA01818 for ; Wed, 6 Apr 2005 12:30:52 -0400 (EDT) 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.01004EA2@cherry.ease.lsoft.com>; Wed, 6 Apr 2005 12:30:43 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 65505743 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 6 Apr 2005 12:30:41 -0400 Received: from 207.17.137.64 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 6 Apr 2005 12:30:40 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id j36GUZBm058616 for ; Wed, 6 Apr 2005 09:30:39 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j36GUZe97414; Wed, 6 Apr 2005 09:30:35 -0700 (PDT) (envelope-from yakov@juniper.net) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <5524.1112805035.1@juniper.net> Message-ID: <200504061630.j36GUZe97414@merlot.juniper.net> Date: Wed, 6 Apr 2005 09:30:35 -0700 Reply-To: Mailing List Sender: Mailing List From: Yakov Rekhter Subject: Re: Working Group Last Call on "Multi-Topology (MT) Routing in OSPF" (draft-ietf-ospf-mt-03.txt) - Corrected To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Your message of "Wed, 06 Apr 2005 09:08:28 PDT." <4254097C.9020901@cisco.com> Precedence: list Peter, > >>This is the start of a Working Group last call for > >>"Multi-Topology (MT) Routing in OSPF" (draft-ietf-ospf-mt-03.txt). > >>All comments should be sent to this list by 12 AM (EDT), 04/19/2005. > >> > >>A URL for this Internet-Draft is: > >>http://www.ietf.org/internet-drafts/draft-ietf-ospf-mt-03.txt > >> > >>The RFC 3978 IPR notices will be updated in the next revision. > > > > > > As the draft correctly points out: > > > > TOS based routing as described in [RFC1583] was never > > deployed and was subsequently deprecated. > > > > So, why computing different paths for different classes of service > > be any different ? > > because MTR allows people to do things that were not possible with the > TOS based routing as described in [RFC1583]. Then the draft should document how this addressed and solved the problems that caused TOS routing being never deployed. Yakov. From owner-ospf@PEACH.EASE.LSOFT.COM Wed Apr 6 13:37: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 NAA09287 for ; Wed, 6 Apr 2005 13:37:29 -0400 (EDT) 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.010051BF@cherry.ease.lsoft.com>; Wed, 6 Apr 2005 13:37:25 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 65516131 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 6 Apr 2005 13:37:22 -0400 Received: from 64.102.122.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 6 Apr 2005 13:37:22 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 06 Apr 2005 13:58:17 -0400 X-IronPort-AV: i="3.92,80,1112587200"; d="scan'208"; a="43399050:sNHT2578915530" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j36Haq1l027169 for ; Wed, 6 Apr 2005 13:36:55 -0400 (EDT) Received: from xfe-rtp-212.amer.cisco.com ([64.102.31.100]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 6 Apr 2005 13:36:54 -0400 Received: from [10.82.241.6] ([10.82.241.6]) by xfe-rtp-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 6 Apr 2005 13:36:53 -0400 User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <200504061334.j36DYIe65964@merlot.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Apr 2005 17:36:53.0945 (UTC) FILETIME=[3908DA90:01C53ACF] Message-ID: <42541E37.4070805@cisco.com> Date: Wed, 6 Apr 2005 13:36:55 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Working Group Last Call on "Multi-Topology (MT) Routing in OSPF" (draft-ietf-ospf-mt-03.txt) - Corrected To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <200504061334.j36DYIe65964@merlot.juniper.net> Precedence: list Content-Transfer-Encoding: 7bit Yakov Rekhter wrote: >Folks, > > > >>This is the start of a Working Group last call for >>"Multi-Topology (MT) Routing in OSPF" (draft-ietf-ospf-mt-03.txt). >>All comments should be sent to this list by 12 AM (EDT), 04/19/2005. >> >>A URL for this Internet-Draft is: >>http://www.ietf.org/internet-drafts/draft-ietf-ospf-mt-03.txt >> >>The RFC 3978 IPR notices will be updated in the next revision. >> >> > >As the draft correctly points out: > > TOS based routing as described in [RFC1583] was never > deployed and was subsequently deprecated. > >So, why computing different paths for different classes of service >be any different ? > > Hi Yakov, In addition to the differences between the two protocol mechanisms, we've evolved technologically since RFC 1583. It is now fairly straight-forward to support multiple topologies (protocol signaling, SPF computations, and logically separate RIBs/FIBs). As for requirements, the example most often given is when a SP wants to provide separate topologies for unicast and multicast services. Note that there is a similar proposal in the ISIS WG so I'd venture to say that there is some agreement on the requirement - draft-ietf-isis-wg-multi-topology-09.txt. Thanks, Acee >Yakov. > > > From owner-ospf@PEACH.EASE.LSOFT.COM Wed Apr 6 17:41:10 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 RAA07372 for ; Wed, 6 Apr 2005 17:41:10 -0400 (EDT) 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.01005A98@cherry.ease.lsoft.com>; Wed, 6 Apr 2005 17:41:10 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 65536429 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 6 Apr 2005 17:40:11 -0400 Received: from 216.37.114.8 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 6 Apr 2005 17:40:11 -0500 Received: (qmail 1682 invoked from network); 6 Apr 2005 21:40:10 -0000 Received: from unknown (HELO ?192.168.1.28?) (172.16.104.135) by lxmail.nj.us.utstar.com with SMTP; 6 Apr 2005 21:40:10 -0000 User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.3) Gecko/20040921 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <200504061334.j36DYIe65964@merlot.juniper.net> <42541E37.4070805@cisco.com> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <4254736B.7030502@xebeo.com> Date: Wed, 6 Apr 2005 23:40:27 +0000 Reply-To: Mailing List Sender: Mailing List From: Tony Przygienda Subject: Re: Working Group Last Call on "Multi-Topology (MT) Routing in OSPF" (draft-ietf-ospf-mt-03.txt) - Corrected To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <42541E37.4070805@cisco.com> Precedence: list Content-Transfer-Encoding: 7bit >> >> So, why computing different paths for different classes of service >> be any different ? >> >> > Hi Yakov, > > In addition to the differences between the two protocol mechanisms, > we've evolved > technologically since RFC 1583. It is now fairly straight-forward to > support multiple > topologies (protocol signaling, SPF computations, and logically > separate RIBs/FIBs). > As for requirements, the example most often given is when a SP wants > to provide > separate topologies for unicast and multicast services. > > Note that there is a similar proposal in the ISIS WG so I'd venture to > say that there > is some agreement on the requirement - > draft-ietf-isis-wg-multi-topology-09.txt. we could always just force diffserv to disavow the TOS bits or, even better, make network operators deploy carefull 'precedence designation remarking nodes' and set metrics for certain TOSes on certain links to infinity and then we would almost have the same good idea, NOT -- tony From owner-ospf@PEACH.EASE.LSOFT.COM Thu Apr 7 01: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 BAA23676 for ; Thu, 7 Apr 2005 01:57:04 -0400 (EDT) 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.010066FB@cherry.ease.lsoft.com>; Thu, 7 Apr 2005 1:57:01 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 65565799 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 7 Apr 2005 01:57:00 -0400 Received: from 171.71.176.71 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 7 Apr 2005 01:57:00 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 06 Apr 2005 22:57:00 -0700 Received: from smirtorawxp (sjc-vpn1-232.cisco.com [10.21.96.232]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j375urZV018465 for ; Wed, 6 Apr 2005 22:56:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0121_01C53AFB.F01F69C0" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcU64E2q38NSuVsKSbyQRS7OFgBdSwAVQ5wg Message-ID: <200504070556.j375urZV018465@sj-core-5.cisco.com> Date: Wed, 6 Apr 2005 22:56:53 -0700 Reply-To: Mailing List Sender: Mailing List From: Sina Mirtorabi Subject: I-D ACTION:draft-mirtorabi-mt-ospfv3-02.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_0121_01C53AFB.F01F69C0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Folks This new version include address-family (integrated approach) in MTRv3. Main changes - Sections 17, 18 are new - section 20.6 has been updated Thanks Sina ---- A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Multi-topology routing in OSPFv3 (MT-OSPFv3) Author(s) : S. Mirtorabi, A. Roy Filename : draft-mirtorabi-mt-ospfv3-02.txt Pages : 25 Date : 2005-4-6 This document describes an extensible mechanism to support multiple topologies (MT) in OSPFv3. These topologies can be used within the same address family in order to compute different paths for different classes of service, or belong to different address families allowing an integrated definition of address family with OSPFv3. The extension described in this document can further facilitate any future extensions of OSPFv3. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mirtorabi-mt-ospfv3-02.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-mirtorabi-mt-ospfv3-02.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-mirtorabi-mt-ospfv3-02.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. ------------------------------------------------------------------------- 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 by this policy. The attachment has been removed from this message and 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 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 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 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 headers is available at this URL: http://wwwin.cisco.com/support/library/faqs/solution002471.html * This unique quarantine identifier: j36JcUgW012635 If the matter is urgent, you may follow up by calling one of the below referenced numbers. Please make every effort to provide the above requested information via the support web tool prior to calling as it 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_0121_01C53AFB.F01F69C0 Content-Type: text/plain; name="ATT00101.txt" Content-Disposition: attachment; filename="ATT00101.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_0121_01C53AFB.F01F69C0-- From owner-ospf@PEACH.EASE.LSOFT.COM Thu Apr 7 02:21: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 CAA14652 for ; Thu, 7 Apr 2005 02:21:00 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.01006696@cherry.ease.lsoft.com>; Thu, 7 Apr 2005 2:21:00 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 65566615 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 7 Apr 2005 02:20:58 -0400 Received: from 66.129.224.36 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 7 Apr 2005 02:20:58 -0500 Received: from kummer.juniper.net (localhost [127.0.0.1]) by kummer.juniper.net (8.12.8p1/8.12.3) with ESMTP id j376KvXg012536 for ; Wed, 6 Apr 2005 23:20:57 -0700 (PDT) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.12.8p1/8.12.3/Submit) with ESMTP id j376Kvdw012533 for ; Wed, 6 Apr 2005 23:20:57 -0700 (PDT) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs References: <00af01c5392d$ba757aa0$0601a8c0@pc6> <20050404145631.L706@kummer.juniper.net> <019701c53a0a$3b66bd40$0601a8c0@pc6> <425351AB.4040308@hp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: <20050406231254.X12461@kummer.juniper.net> Date: Wed, 6 Apr 2005 23:20:57 -0700 Reply-To: Mailing List Sender: Mailing List From: Kireeti Kompella Subject: Re: draft-ietf-ospf-iana-00 To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <425351AB.4040308@hp.com> Precedence: list On Tue, 5 Apr 2005, John Flick wrote: > Actually, this information is true for ISO ASN.1, but not for SNMP. > SNMP's SMI is an "adapted subset" of ASN.1. That subset is defined > in RFCs 2578-2580. You live and learn how little you really know! > From RFC 2578, section 3.5: > > An OBJECT IDENTIFIER value is an ordered list of non-negative > numbers. For the SMIv2, each number in the list is referred to as a > sub-identifier, there are at most 128 sub-identifiers in a value, and > each sub-identifier has a maximum value of 232-1 (4294967295 > decimal). Can we now start a thread on whether an OID length of 128 is too small? :-) > I don't believe we have run into any problems with these limits in > SNMP :-) . > > So, I don't believe that draft-ietf-ospf-iana draft has a problem here. Whew! For a while there, I was worried that we would need 2^128 enterprise codes (and 2^128 enterprises to use them!) :-) Kireeti. ------- From owner-ospf@PEACH.EASE.LSOFT.COM Thu Apr 7 02:49: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 CAA19100 for ; Thu, 7 Apr 2005 02:49:50 -0400 (EDT) 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.010067E8@cherry.ease.lsoft.com>; Thu, 7 Apr 2005 2:49:50 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 65567188 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 7 Apr 2005 02:49:49 -0400 Received: from 171.71.176.72 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 7 Apr 2005 02:39:49 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-3.cisco.com with ESMTP; 06 Apr 2005 23:39:32 -0700 X-IronPort-AV: i="3.92,82,1112598000"; d="scan'208"; a="246818829:sNHT1821034982" Received: from [127.0.0.1] (ssh-sjc-1.cisco.com [171.68.225.134]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j376dUgS016481 for ; Wed, 6 Apr 2005 23:39:30 -0700 (PDT) User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <200504061334.j36DYIe65964@merlot.juniper.net> <42541E37.4070805@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <4254D5A5.5050604@cisco.com> Date: Wed, 6 Apr 2005 23:39:33 -0700 Reply-To: Mailing List Sender: Mailing List From: Naiming Shen Subject: Re: Working Group Last Call on "Multi-Topology (MT) Routing in OSPF" (draft-ietf-ospf-mt-03.txt) - Corrected To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <42541E37.4070805@cisco.com> Precedence: list Content-Transfer-Encoding: 7bit < cut ...> > As for requirements, the example most often given is when a SP wants to > provide separate topologies for unicast and multicast services. > I was told at least one ISP used MT isis to link remote IPv6 POPs through GRE tunnels, IPv4 topology was not enabled on those tunnels. thanks. - Naiming > Note that there is a similar proposal in the ISIS WG so I'd venture to > say that there > is some agreement on the requirement - > draft-ietf-isis-wg-multi-topology-09.txt. > > Thanks, > Acee From owner-ospf@PEACH.EASE.LSOFT.COM Sun Apr 10 07:12: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 HAA10379 for ; Sun, 10 Apr 2005 07:12:34 -0400 (EDT) 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.0100AF9F@cherry.ease.lsoft.com>; 10 Apr 2005 7:12:28 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 65936749 for OSPF@PEACH.EASE.LSOFT.COM; Sun, 10 Apr 2005 07:12:23 -0400 Received: from 147.234.1.11 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sun, 10 Apr 2005 07:12:22 -0500 X-Mailer: Lotus Notes Release 5.0.2b (Intl) 16 December 1999 X-MIMETrack: Serialize by Router on ILSMTP01/ECI Telecom(Release 6.5.1|January 21, 2004) at 04/10/2005 14:17:23 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Message-ID: Date: Sun, 10 Apr 2005 15:12:27 +0300 Reply-To: Mailing List Sender: Mailing List From: Ilan Bercovich Subject: Equal-cost path To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Hi, When not using "equal-cost multipath", Which equal-cost path should be selected? Thanks - Ilan From owner-ospf@PEACH.EASE.LSOFT.COM Mon Apr 11 09:50:16 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 JAA14444 for ; Mon, 11 Apr 2005 09:50:15 -0400 (EDT) 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.0100CBE0@cherry.ease.lsoft.com>; Mon, 11 Apr 2005 9:50:13 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 66077858 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 11 Apr 2005 09:50:09 -0400 Received: from 207.17.137.64 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 11 Apr 2005 09:50:07 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id j3BDo6Bm092153 for ; Mon, 11 Apr 2005 06:50:06 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j3BDo5e79822; Mon, 11 Apr 2005 06:50:05 -0700 (PDT) (envelope-from yakov@juniper.net) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <31967.1113227405.1@juniper.net> Message-ID: <200504111350.j3BDo5e79822@merlot.juniper.net> Date: Mon, 11 Apr 2005 06:50:05 -0700 Reply-To: Mailing List Sender: Mailing List From: Yakov Rekhter Subject: Re: Working Group Last Call on "Multi-Topology (MT) Routing in OSPF" (draft-ietf-ospf-mt-03.txt) - Corrected To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Your message of "Wed, 06 Apr 2005 23:39:33 PDT." <4254D5A5.5050604@cisco.com> Precedence: list Naiming, > < cut ...> > > As for requirements, the example most often given is when a SP wants to > > provide separate topologies for unicast and multicast services. > > > > I was told at least one ISP used MT isis to link remote IPv6 POPs > through GRE tunnels, IPv4 topology was not enabled on those tunnels. That is fine. But what that has to do with computing different paths for different classes of service ? Yakov. > > thanks. > - Naiming > > > Note that there is a similar proposal in the ISIS WG so I'd venture to > > say that there > > is some agreement on the requirement - > > draft-ietf-isis-wg-multi-topology-09.txt. > > > > Thanks, > > Acee From owner-ospf@PEACH.EASE.LSOFT.COM Tue Apr 12 18:40: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 SAA20228 for ; Tue, 12 Apr 2005 18:40:46 -0400 (EDT) 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.0100F001@cherry.ease.lsoft.com>; Tue, 12 Apr 2005 18:40:32 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 66271564 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 12 Apr 2005 18:40:31 -0400 Received: from 66.129.224.36 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 12 Apr 2005 18:40:31 -0500 Received: from kummer.juniper.net (localhost [127.0.0.1]) by kummer.juniper.net (8.12.8p1/8.12.3) with ESMTP id j3CMeU1l019815 for ; Tue, 12 Apr 2005 15:40:30 -0700 (PDT) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.12.8p1/8.12.3/Submit) with ESMTP id j3CMeUGa019812 for ; Tue, 12 Apr 2005 15:40:30 -0700 (PDT) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: <20050412154007.R19808@kummer.juniper.net> Date: Tue, 12 Apr 2005 15:40:29 -0700 Reply-To: Mailing List Sender: Mailing List From: Kireeti Kompella Subject: Re: Equal-cost path To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list On Sun, 10 Apr 2005, Ilan Bercovich wrote: > When not using "equal-cost multipath", > Which equal-cost path should be selected? The one that's more equal than the rest. Kireeti. ------- From owner-ospf*ospf-archive**LISTS*-IETF*-ORG@PEACH.EASE.LSOFT.COM Tue Apr 12 19:01:15 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 TAA21877 for ; Tue, 12 Apr 2005 19:01:15 -0400 (EDT) Received: from PEACH.EASE.LSOFT.COM (209.119.1.45) by grape.ease.lsoft.com (LSMTP for OpenVMS v1.1b) with SMTP id <11.00564F4F@grape.ease.lsoft.com>; Tue, 12 Apr 2005 19:01:17 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 66274097 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 12 Apr 2005 19:01:17 -0400 Received: from 203.178.143.91 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 12 Apr 2005 19:01:13 -0500 Received: from localhost (p16006-ipad46hodogaya.kanagawa.ocn.ne.jp [60.33.95.6]) by plant.sfc.wide.ad.jp (Postfix) with ESMTP id 4DEF41B66A; Wed, 13 Apr 2005 08:01:10 +0900 (JST) References: <20050412154007.R19808@kummer.juniper.net> X-Mailer: Mew version 4.2 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20050413.080109.01294295.yasu@sfc.wide.ad.jp> Date: Wed, 13 Apr 2005 08:01:09 +0900 Reply-To: Mailing List Sender: Mailing List From: Yasuhiro Ohara Subject: Re: Equal-cost path Comments: To: kireeti@JUNIPER.NET To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <20050412154007.R19808@kummer.juniper.net> Precedence: list Content-Transfer-Encoding: 7bit Ahahaha, what are you talking about Kireeti !? ;p) The correct answer would be "It's an implementation specific issue". One should recognize ECMP as a property of OSPF (dijkstra) algorithm, rather than a feature. It means "you can use either path as far as those paths are equal cost". Which path to use actually is totally left to the calculating router. Whichever the path is selected by the router whole OSPF domain will work fine (in terms of issue regarding routing loops). OSPF does not specify which path (out of ECMP) should be used/preferred, it's totally left to a implementor. regards, yasu From: Kireeti Kompella Subject: Re: Equal-cost path Date: Tue, 12 Apr 2005 15:40:29 -0700 > On Sun, 10 Apr 2005, Ilan Bercovich wrote: > > > When not using "equal-cost multipath", > > Which equal-cost path should be selected? > > The one that's more equal than the rest. > > Kireeti. > ------- > From owner-ospf@PEACH.EASE.LSOFT.COM Tue Apr 12 20:12:59 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 UAA28158 for ; Tue, 12 Apr 2005 20:12:59 -0400 (EDT) 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.0100F3A2@cherry.ease.lsoft.com>; Tue, 12 Apr 2005 20:13:01 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 66280948 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 12 Apr 2005 20:13:00 -0400 Received: from 66.129.224.36 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 12 Apr 2005 20:13:00 -0500 Received: from kummer.juniper.net (localhost [127.0.0.1]) by kummer.juniper.net (8.12.8p1/8.12.3) with ESMTP id j3D0Cx1l020140 for ; Tue, 12 Apr 2005 17:12:59 -0700 (PDT) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.12.8p1/8.12.3/Submit) with ESMTP id j3D0CxXT020137 for ; Tue, 12 Apr 2005 17:12:59 -0700 (PDT) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs References: <20050412154007.R19808@kummer.juniper.net> <20050413.080109.01294295.yasu@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: <20050412164915.J19808@kummer.juniper.net> Date: Tue, 12 Apr 2005 17:12:58 -0700 Reply-To: Mailing List Sender: Mailing List From: Kireeti Kompella Subject: Re: Equal-cost path To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <20050413.080109.01294295.yasu@sfc.wide.ad.jp> Precedence: list On Wed, 13 Apr 2005, Yasuhiro Ohara wrote: > Ahahaha, > what are you talking about Kireeti !? ;p) Four legs good, two legs better, one path best. > The correct answer would be "It's an implementation specific issue". ... > Whichever the path is selected by the router whole OSPF domain will > work fine (in terms of issue regarding routing loops). I think we're saying the same thing, just using different words. But you said it somewhat more clearly. Kireeti. ------- From owner-ospf@PEACH.EASE.LSOFT.COM Wed Apr 13 10:38: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 KAA01856 for ; Wed, 13 Apr 2005 10:38:22 -0400 (EDT) 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.01010365@cherry.ease.lsoft.com>; Wed, 13 Apr 2005 10:38:20 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 66380424 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 13 Apr 2005 10:38:18 -0400 Received: from 169.144.68.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 13 Apr 2005 10:38:18 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id j3DEcH0E020925 for ; Wed, 13 Apr 2005 10:38:17 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA01958 for ; Wed, 13 Apr 2005 10:38:17 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id ; Wed, 13 Apr 2005 10:38:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <5551AD75D2C0BC459A85A2CEFAE4F80050C7D4@usvissfp01.win.marconi.com> Date: Wed, 13 Apr 2005 10:38:15 -0400 Reply-To: Mailing List Sender: Mailing List From: "Naidu, Venkata" Subject: Re: Equal-cost path To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list -> The correct answer would be "It's an implementation specific issue". -> -> > On Sun, 10 Apr 2005, Ilan Bercovich wrote: -> > -> > > When not using "equal-cost multipath", -> > > Which equal-cost path should be selected? A good heuristic is - select a path where there are fewer number nodes along the path. Note that, IGPs don't include node weights in SPD (Shortest Path Dag) computation. But, nodes/routers are very crucial in forwarding traffic in the data path. If we assuming all nodes in an area have same capabilities (like, line rate forwarding etc), fewer number node path performs better in the average case. Venkat. From owner-ospf@PEACH.EASE.LSOFT.COM Wed Apr 13 14:48: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 OAA21873 for ; Wed, 13 Apr 2005 14:47:59 -0400 (EDT) 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.010108B5@cherry.ease.lsoft.com>; Wed, 13 Apr 2005 14:47:57 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 66405011 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 13 Apr 2005 14:47:56 -0400 Received: from 207.17.137.57 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 13 Apr 2005 14:47:56 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id j3DIlt922041 for ; Wed, 13 Apr 2005 11:47:55 -0700 (PDT) (envelope-from dkatz@juniper.net) Received: from [172.16.12.13] (nimbus-sc.juniper.net [172.16.12.13]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j3DIloe56033 for ; Wed, 13 Apr 2005 11:47:50 -0700 (PDT) (envelope-from dkatz@juniper.net) Mime-Version: 1.0 (Apple Message framework v619.2) References: <5551AD75D2C0BC459A85A2CEFAE4F80050C7D4@usvissfp01.win.marconi.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.619.2) Message-ID: <14f33d018be89c528d9646f864cd5ed9@juniper.net> Date: Wed, 13 Apr 2005 11:47:50 -0700 Reply-To: Mailing List Sender: Mailing List From: Dave Katz Subject: Re: Equal-cost path To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <5551AD75D2C0BC459A85A2CEFAE4F80050C7D4@usvissfp01.win.marconi.com> Precedence: list Content-Transfer-Encoding: 7bit On Apr 13, 2005, at 7:38 AM, Naidu, Venkata wrote: > If we assuming all nodes in an area have same > capabilities (like, line rate forwarding etc), fewer number > node path performs better in the average case. > I do not believe that you can make this claim, except in a simulation, which has little to do with reality. In real networks, with reasonably fast routers and links, the performance of the routers and per-link serialization are greatly overwhelmed by other issues (such as the speed of light and queue lengths.) One could just as plausibly posit that, on average, a random assignment in the case of equal path costs could improve performance by spreading the load more effectively across the infrastructure, but it totally depends on the particulars of equipment, topology, and traffic. A case could also be made that well-engineered networks ought not to have equal cost paths by accident; most of the time they should only appear if the network engineers wanted to take advantage of path splitting. In any case, a router that did not support equal cost multipath would be so broken that nobody would buy it, making the whole question academic. --Dave From owner-ospf@PEACH.EASE.LSOFT.COM Wed Apr 13 15:40:17 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 PAA26783 for ; Wed, 13 Apr 2005 15:40:16 -0400 (EDT) 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.0101091A@cherry.ease.lsoft.com>; Wed, 13 Apr 2005 15:40:17 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 66408382 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 13 Apr 2005 15:40:10 -0400 Received: from 169.144.68.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 13 Apr 2005 15:40:10 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id j3DJe80E029104 for ; Wed, 13 Apr 2005 15:40:09 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA09193 for ; Wed, 13 Apr 2005 15:40:08 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id ; Wed, 13 Apr 2005 15:40:07 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <5551AD75D2C0BC459A85A2CEFAE4F80050C7D5@usvissfp01.win.marconi.com> Date: Wed, 13 Apr 2005 15:40:06 -0400 Reply-To: Mailing List Sender: Mailing List From: "Naidu, Venkata" Subject: Re: Equal-cost path To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list -> > If we assuming all nodes in an area have same -> > capabilities (like, line rate forwarding etc), fewer number -> > node path performs better in the average case. -> > -> -> I do not believe that you can make this claim, except in a -> simulation, which has little to do with reality. I don't think so...[please read on] -> In real networks, with reasonably fast routers and links, the -> performance of the routers and per-link serialization are greatly -> overwhelmed by other issues (such as the speed of light and queue -> lengths.) That is why I said, "in the average case", where the assumption is all the routers in an area have equal capabilities. In such a a case, simple queuing theory would suffice to prove that shorter paths minimizes delay (if link costs are all same). Practically, any service provider buying bunch of routers, never going mix routers from different providers in an IGP area. Simply, can't justify for non-technical reasons. The assumption that an IGP area has equal capable routers is a valid assumption. If not, why don't we have a router metric in Router LSA ? -> One could just as plausibly posit that, on average, a random -> assignment -> in the case of equal path costs could improve performance by -> spreading -> the load more effectively across the infrastructure, but it totally -> depends on the particulars of equipment, topology, and traffic. Most of the cases, a deterministic algorithm performs better than non-deterministic algorithm. Randomized selections of equal-cost paths can bring instability. Take this for example: If IGP is flapping between equal-cost paths in a non-deterministic manner would increase out-of-order IP packets. This makes overhead for higher layers waiting for all IP datagrams to make out a transport packet. It is always better to send all IP datagrams of an application packet on a single deterministic path. That said, non-determinism and randomized algorithms are good for proving theorems like probabilistic checkable proofs etc. Venkat. From owner-ospf@PEACH.EASE.LSOFT.COM Wed Apr 13 17:05: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 RAA07394 for ; Wed, 13 Apr 2005 17:05:48 -0400 (EDT) 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.01010CDF@cherry.ease.lsoft.com>; Wed, 13 Apr 2005 17:05:48 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 66414963 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 13 Apr 2005 17:05:42 -0400 Received: from 207.17.137.57 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 13 Apr 2005 17:05:42 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id j3DL5g923523 for ; Wed, 13 Apr 2005 14:05:42 -0700 (PDT) (envelope-from dkatz@juniper.net) Received: from [172.16.12.13] (nimbus-sc.juniper.net [172.16.12.13]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j3DL5ae86116 for ; Wed, 13 Apr 2005 14:05:36 -0700 (PDT) (envelope-from dkatz@juniper.net) Mime-Version: 1.0 (Apple Message framework v619.2) References: <5551AD75D2C0BC459A85A2CEFAE4F80050C7D5@usvissfp01.win.marconi.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.619.2) Message-ID: <2528b1ee5980eaa9a9078eab2b321324@juniper.net> Date: Wed, 13 Apr 2005 14:05:36 -0700 Reply-To: Mailing List Sender: Mailing List From: Dave Katz Subject: Re: Equal-cost path To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <5551AD75D2C0BC459A85A2CEFAE4F80050C7D5@usvissfp01.win.marconi.com> Precedence: list Content-Transfer-Encoding: 7bit On Apr 13, 2005, at 12:40 PM, Naidu, Venkata wrote: > -> In real networks, with reasonably fast routers and links, the > -> performance of the routers and per-link serialization are greatly > -> overwhelmed by other issues (such as the speed of light and queue > -> lengths.) > > That is why I said, "in the average case", where the assumption > is all the routers in an area have equal capabilities. In such a > a case, simple queuing theory would suffice to prove that > shorter paths minimizes delay (if link costs are all same). There is no "average case" in reality. It's totally nonpredictive. Real networks and routers don't follow simple queuing theory either; their behaviors are dominated by the particulars of implementation. I don't build theoretical, average equipment; I build real equipment that runs in real networks. > Practically, any service provider buying bunch of routers, never > going mix routers from different providers in an IGP area. Simply, > can't justify for non-technical reasons. Another nice theory with absolutely no grounding in reality. This is demonstrably not true in very many networks, and likely is not true in almost all large ISPs (or my current employer would have never gotten off the ground, and the world would have been even more dominated by my previous employer.) Multivendor networks are extremely common. > The assumption that > an IGP area has equal capable routers is a valid assumption. > If not, why don't we have a router metric in Router LSA ? It's not a valid assumption; I think you'll find very few networks in which all routers are identical. Even single-vendor networks have multiple models of routers with different capabilities. There's no metric in the router LSA because it was deemed unimportant even in 1988, and is arguably even less important now due to the negligible impact of the routers relative to the links, though trying to claim *anything* based on design decisions made by committee during the Reagan administration is silly. > Take this for example: If IGP is flapping between equal-cost paths > in a non-deterministic manner would increase out-of-order IP packets. > This makes overhead for higher layers waiting for all IP datagrams > to make out a transport packet. It is always better to send all IP > datagrams of an application packet on a single deterministic path. I did not make myself sufficiently clear. I was not suggesting choosing random paths per packet, but rather per-route (or even per-flow.) Even with multiple next hops, most routers default to a behavior in which subsets of the traffic (based on flow, if possible) are bound to particular, single next hops. The traffic for a single flow follows a particular single path, and the flows are spread across the multiple paths. This simultaneously avoids packet reordering while providing predictable paths and good resource utilization. --Dave From owner-ospf@PEACH.EASE.LSOFT.COM Wed Apr 13 18:25: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 SAA13877 for ; Wed, 13 Apr 2005 18:25:57 -0400 (EDT) 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.01010DE2@cherry.ease.lsoft.com>; Wed, 13 Apr 2005 18:25:58 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 66420193 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 13 Apr 2005 18:25:56 -0400 Received: from 207.217.121.205 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 13 Apr 2005 18:25:55 -0400 Received: from h-68-164-158-70.snvacaid.dynamic.covad.net ([68.164.158.70] helo=earthlink.net) by pop-a065c28.pas.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1DLqJ0-0001p6-00 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 13 Apr 2005 15:25:55 -0700 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: <5551AD75D2C0BC459A85A2CEFAE4F80050C7D4@usvissfp01.win.marconi.com> <14f33d018be89c528d9646f864cd5ed9@juniper.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <425D9DD6.E6921764@earthlink.net> Date: Wed, 13 Apr 2005 15:31:50 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: Equal-cost path To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Group, et al, I would like to agree with Dave Katz. However, I would like to expound on just a couple of items. First, at the hardware layer, in my experience with Ethernet, you want to bunch packets together so as to be able to process a group of packets with a single interrupt. Secondly, if we assume OSPF control Updates with new link information, I would hope that these would be processed together and generate only 1 later computation. Thirdly, if we are looking at a single data stream that in theory has a set of packets being handled on both ends by TCP, if only a singe TCP packet is delayed or expedited and arrives out of order, we can easily generate a false fast retransmit. Fourth, most TCP paths need a baicly constant flow of packets in-flight to determine congestion and be able to run network limited flows vs application limited flows. With the later, and any changes, the end-points are unable to determine whethe the those paths have changed wrt congestion behaviour. So in theory spreading the load over multiple paths is not a panacea, but is a sensible thing to determine congestion over the different paths, and to be able to generate predictable time measurements. Mitchell Erblich ------------------------ Dave Katz wrote: > > On Apr 13, 2005, at 7:38 AM, Naidu, Venkata wrote: > > > If we assuming all nodes in an area have same > > capabilities (like, line rate forwarding etc), fewer number > > node path performs better in the average case. > > > > I do not believe that you can make this claim, except in a simulation, > which has little to do with reality. > > In real networks, with reasonably fast routers and links, the > performance of the routers and per-link serialization are greatly > overwhelmed by other issues (such as the speed of light and queue > lengths.) > > One could just as plausibly posit that, on average, a random assignment > in the case of equal path costs could improve performance by spreading > the load more effectively across the infrastructure, but it totally > depends on the particulars of equipment, topology, and traffic. > > A case could also be made that well-engineered networks ought not to > have equal cost paths by accident; most of the time they should only > appear if the network engineers wanted to take advantage of path > splitting. > > In any case, a router that did not support equal cost multipath would > be so broken that nobody would buy it, making the whole question > academic. > > --Dave From owner-ospf@PEACH.EASE.LSOFT.COM Wed Apr 13 20:11: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 UAA22112 for ; Wed, 13 Apr 2005 20:11:11 -0400 (EDT) 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.0101125C@cherry.ease.lsoft.com>; Wed, 13 Apr 2005 20:11:08 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 66427944 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 13 Apr 2005 20:11:07 -0400 Received: from 64.102.122.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 13 Apr 2005 20:11:07 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 13 Apr 2005 20:11:08 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j3E0B5Hd029077 for ; Wed, 13 Apr 2005 20:11:05 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 13 Apr 2005 20:11:05 -0400 Received: from [10.82.224.48] ([10.82.224.48]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 13 Apr 2005 20:11:05 -0400 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 X-OriginalArrivalTime: 14 Apr 2005 00:11:05.0195 (UTC) FILETIME=[732B73B0:01C54086] Message-ID: <425DB518.9060907@cisco.com> Date: Wed, 13 Apr 2005 20:11:04 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: OSPFv3 Extension Future Direction To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit We've looked at the requirement to support OSPFv3 MTR (multi-topology routing) for more than a year now. Many articulated the requirement for a solution that will do this with a single OSPFv3 adjacency (similar to our OSPFv2 MTR solution). We tried to shoe-horn this in using the existing LSAs and it really didn't fit. Hence, we will need new LSAs. We could support it with new MTR specific LSAs. However, at the Minneapolis IETF I advocated the draft-mirtorabi-mt-ospfv3-02.txt as mechanism to support MTR and provide a more extensible basic LSA encoding for future OSPFv3 enhancements. We've had some discussion both at the IETF and on the WG list. All the discussion has been positive with some suggestions that we should go ever further with changes to OSPFv3. At this point, Rohit and I agree that we should make draft-mirtorabi-mt-ospfv3-02.txt a WG document and elicit further discussion. Thanks, Acee From owner-ospf@PEACH.EASE.LSOFT.COM Thu Apr 14 19:42: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 TAA12018 for ; Thu, 14 Apr 2005 19:42:02 -0400 (EDT) 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.010141D3@cherry.ease.lsoft.com>; Thu, 14 Apr 2005 19:42:01 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 66609131 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 14 Apr 2005 19:42:00 -0400 Received: from 47.129.242.57 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 14 Apr 2005 19:32:00 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j3ENVwQ09257 for ; Thu, 14 Apr 2005 19:31:58 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id <2KL17A63>; Thu, 14 Apr 2005 19:31:58 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5414A.212D1508" Message-ID: <7A3E36B3528ED04A880178D337F30C9A044F6285@zrc2hxm1.corp.nortel.com> Date: Thu, 14 Apr 2005 19:31:47 -0400 Reply-To: Mailing List Sender: Mailing List From: Zhao-Yang Dong To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C5414A.212D1508 Content-Type: text/plain In an OSPF link state database, each LSA is supposed to have a unique Link State ID (LSID). Sometimes this is not true, especially in multiple vendor devices environment. When originating summary and/or AS-external LSAs, how to assign unique LSID for a network number who has multiple (different length of) masks is described in RFC 2328 appendix E. However, I did not see any discussion in RFC 2328 nor this archive how to handle/process summary and/or AS-external LSAs received from other routers with the same LSID but different length of masks. According RFC 2328, a LSA is identified by LS type, LSID and advertising router. To determine which LSA of two LSA instances is newer, LS sequence number, checksum and age are compared. Network mask does not seem play any role while processing the received LSAs. My question is, for example, if I received a LSA with LSID=A.B.C.D and 24 bits mask and installed in my database, and later I received the same LSA (i.e. same LS type, LSID and advertising router) but with 28 bits mask. If the second LSA has the larger sequence number, should I replace my database copy with the second LSA? Thanks, Zhaoyang ------_=_NextPart_001_01C5414A.212D1508 Content-Type: text/html

In an OSPF link state database, each LSA is supposed to have a unique Link State ID (LSID). Sometimes this is not true, especially in multiple vendor devices environment.

 

When originating summary and/or AS-external LSAs, how to assign unique LSID for a network number who has multiple (different length of) masks is described in RFC 2328 appendix E. However, I did not see any discussion in RFC 2328 nor this archive how to handle/process summary and/or AS-external LSAs received from other routers with the same LSID but different length of masks.

 

According RFC 2328, a LSA is identified by LS type, LSID and advertising router. To determine which LSA of two LSA instances is newer, LS sequence number, checksum and age are compared. Network mask does not seem play any role while processing the received LSAs.

 

My question is, for example, if I received a LSA with LSID=A.B.C.D and 24 bits mask and installed in my database, and later I received the same LSA (i.e. same LS type, LSID and advertising router) but with 28 bits mask. If the second LSA has the larger sequence number, should I replace my database copy with the second LSA?

 

Thanks,

Zhaoyang

 

------_=_NextPart_001_01C5414A.212D1508-- From owner-ospf@PEACH.EASE.LSOFT.COM Fri Apr 15 01:26: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 BAA03965 for ; Fri, 15 Apr 2005 01:26:57 -0400 (EDT) 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.0101489D@cherry.ease.lsoft.com>; Fri, 15 Apr 2005 1:26:53 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 66633614 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 15 Apr 2005 01:26:51 -0400 Received: from 207.17.137.57 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 15 Apr 2005 01:26:51 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id j3F5QQ937882 for ; Thu, 14 Apr 2005 22:26:31 -0700 (PDT) (envelope-from dkatz@juniper.net) Received: from [172.16.12.201] (nimbus-bsr.juniper.net [172.16.12.201]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j3F5QKe11876 for ; Thu, 14 Apr 2005 22:26:20 -0700 (PDT) (envelope-from dkatz@juniper.net) Mime-Version: 1.0 (Apple Message framework v619.2) References: <7A3E36B3528ED04A880178D337F30C9A044F6285@zrc2hxm1.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: Apple Mail (2.619.2) Message-ID: <3a414d026ebf930c4160d09a978134ad@juniper.net> Date: Thu, 14 Apr 2005 22:26:19 -0700 Reply-To: Mailing List Sender: Mailing List From: Dave Katz To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <7A3E36B3528ED04A880178D337F30C9A044F6285@zrc2hxm1.corp.nortel.com> Precedence: list Content-Transfer-Encoding: quoted-printable On Apr 14, 2005, at 4:31 PM, Zhao-Yang Dong wrote: > In an OSPF link state database, each LSA is supposed to have a unique=20= > Link State ID (LSID). Sometimes this is not true, especially in=20 > multiple vendor devices environment. The LSA ID is qualified by the originating system, so it is entirely=20 reasonable to have multiple LSAs with the same LSA ID but different=20 router IDs. What is *not* allowed is to have multiple LSAs with the same LSA ID=20 originated by the same system. This cannot happen according to the=20 rules, and they will not be propagated if they were, also according to=20= the rules. Whether there are multiple vendors has no impact on this. > When originating summary and/or AS-external LSAs, how to assign unique=20= > LSID for a network number who has multiple (different length of) masks=20= > is described in RFC 2328 appendix E. However, I did not see any=20 > discussion in RFC 2328 nor this archive how to handle/process summary=20= > and/or AS-external LSAs received from other routers with the same LSID=20= > but different length of masks. A router can do anything it wants to guarantee LSA ID uniqueness on the=20= LSAs it generates; appendix E is one way (though there are ways that=20 will go further before they fail than the one outlined there.) Note=20 that RFC2328 also refers to appendix E for Summary LSAs as well; see=20 appendix A.4.5. It is not the job of a receiving router to deal with this case, because=20= it cannot happen (according to the rules) and it is indistinguishable=20 from the case where somebody changes the netmask on a redistributed=20 static route. > > =A0 > > According RFC 2328, a LSA is identified by LS type, LSID and=20 > advertising router. To determine which LSA of two LSA instances is=20 > newer, LS sequence number, checksum and age are compared. Network mask=20= > does not seem play any role while processing the received LSAs. It does not, nor should it. An LSA is identified by originating router=20= ID, LSA type, and LSA ID. Period. Any router that attempts to=20 generate two different LSAs with the same ID is broken. > > =A0 > > My question is, for example, if I received a LSA with LSID=3DA.B.C.D = and=20 > 24 bits mask and installed in my database, and later I received the=20 > same LSA (i.e. same LS type, LSID and advertising router) but with 28=20= > bits mask. If the second LSA has the larger sequence number, should I=20= > replace my database copy with the second LSA? That's what the rules say. This is why a broken system generating=20 multiple LSAs with the same ID will not get far; only one of them=20 (with the higher sequence number) will get acknowledged, and the other=20= will be retransmitted ad infinitum. The problem is that the Founding Fathers that spec'ed OSPF screwed up=20 and overloaded the LSA ID with routing information because they were=20 afraid of spending another four bytes per LSA. One could blame it on=20 classful networking, but in a purely classful environment you wouldn't=20= even need masks. Basically it was yet another mistaken optimization. It's impossible to guarantee uniqueness; if you try hard enough you=20 can generate a situation that no algorithm can work around (because the=20= LSA ID space is by definition sparse due to the masking requirement,=20 but the space of possible external routes is dense.) As a practical=20 matter, however, it's very unlikely that there will be an LSA ID=20 collision if a reasonably good algorithm is chosen. BTW, the cisco IOS implementation appears to attempt to detect this=20 case, though it's not clear why. I assume it complains if it sees the=20= same LSA ID and a different netmask, but that's a perfectly legal=20 situation. If anybody from cisco can explain this, I'm quite curious. --Dave > > =A0 > > Thanks, > > Zhaoyang > > =A0 From owner-ospf@PEACH.EASE.LSOFT.COM Fri Apr 15 06:26: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 GAA14582 for ; Fri, 15 Apr 2005 06:26:42 -0400 (EDT) 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.01014C47@cherry.ease.lsoft.com>; Fri, 15 Apr 2005 6:26:41 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 66680461 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 15 Apr 2005 06:26:40 -0400 Received: from 62.241.162.32 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 15 Apr 2005 06:26:39 -0400 Received: from pc6 (1Cust73.tnt108.lnd4.gbr.da.uu.net [62.188.170.73]) by ranger.systems.pipex.net (Postfix) with SMTP id 4CE51E000220 for ; Fri, 15 Apr 2005 11:26:37 +0100 (BST) References: <7A3E36B3528ED04A880178D337F30C9A044F6285@zrc2hxm1.corp.nortel.com> <3a414d026ebf930c4160d09a978134ad@juniper.net> 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.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-ID: <01d001c5419c$bd05ba60$0601a8c0@pc6> Date: Fri, 15 Apr 2005 11:22:57 +0200 Reply-To: Mailing List Sender: Mailing List From: Tom Petch To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Agree with everything Dave saids but would stress that OSPF by design does not cater for overlapping prefix (from the same router) so a router MUST NOT originate two LSA, one a /24 and the other a /28 for the same prefix. Other routing protocols are different which is an issue when redistributing from them into OSPF. Tom Petch ----- Original Message ----- From: "Dave Katz" To: Sent: Friday, April 15, 2005 7:26 AM On Apr 14, 2005, at 4:31 PM, Zhao-Yang Dong wrote: > In an OSPF link state database, each LSA is supposed to have a unique > Link State ID (LSID). Sometimes this is not true, especially in > multiple vendor devices environment. The LSA ID is qualified by the originating system, so it is entirely reasonable to have multiple LSAs with the same LSA ID but different router IDs. What is *not* allowed is to have multiple LSAs with the same LSA ID originated by the same system. This cannot happen according to the rules, and they will not be propagated if they were, also according to the rules. Whether there are multiple vendors has no impact on this. > When originating summary and/or AS-external LSAs, how to assign unique > LSID for a network number who has multiple (different length of) masks > is described in RFC 2328 appendix E. However, I did not see any > discussion in RFC 2328 nor this archive how to handle/process summary > and/or AS-external LSAs received from other routers with the same LSID > but different length of masks. A router can do anything it wants to guarantee LSA ID uniqueness on the LSAs it generates; appendix E is one way (though there are ways that will go further before they fail than the one outlined there.) Note that RFC2328 also refers to appendix E for Summary LSAs as well; see appendix A.4.5. It is not the job of a receiving router to deal with this case, because it cannot happen (according to the rules) and it is indistinguishable from the case where somebody changes the netmask on a redistributed static route. > > > > According RFC 2328, a LSA is identified by LS type, LSID and > advertising router. To determine which LSA of two LSA instances is > newer, LS sequence number, checksum and age are compared. Network mask > does not seem play any role while processing the received LSAs. It does not, nor should it. An LSA is identified by originating router ID, LSA type, and LSA ID. Period. Any router that attempts to generate two different LSAs with the same ID is broken. > > > > My question is, for example, if I received a LSA with LSID=A.B.C.D and > 24 bits mask and installed in my database, and later I received the > same LSA (i.e. same LS type, LSID and advertising router) but with 28 > bits mask. If the second LSA has the larger sequence number, should I > replace my database copy with the second LSA? That's what the rules say. This is why a broken system generating multiple LSAs with the same ID will not get far; only one of them (with the higher sequence number) will get acknowledged, and the other will be retransmitted ad infinitum. The problem is that the Founding Fathers that spec'ed OSPF screwed up and overloaded the LSA ID with routing information because they were afraid of spending another four bytes per LSA. One could blame it on classful networking, but in a purely classful environment you wouldn't even need masks. Basically it was yet another mistaken optimization. It's impossible to guarantee uniqueness; if you try hard enough you can generate a situation that no algorithm can work around (because the LSA ID space is by definition sparse due to the masking requirement, but the space of possible external routes is dense.) As a practical matter, however, it's very unlikely that there will be an LSA ID collision if a reasonably good algorithm is chosen. BTW, the cisco IOS implementation appears to attempt to detect this case, though it's not clear why. I assume it complains if it sees the same LSA ID and a different netmask, but that's a perfectly legal situation. If anybody from cisco can explain this, I'm quite curious. --Dave > > > > Thanks, > > Zhaoyang > > From owner-ospf@PEACH.EASE.LSOFT.COM Fri Apr 15 08:20: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 IAA24746 for ; Fri, 15 Apr 2005 08:20:18 -0400 (EDT) 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.01014E1B@cherry.ease.lsoft.com>; Fri, 15 Apr 2005 8:20:17 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 66691017 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 15 Apr 2005 08:20:16 -0400 Received: from 64.102.122.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 15 Apr 2005 08:20:16 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 15 Apr 2005 08:20:16 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j3FCK7dx016541 for ; Fri, 15 Apr 2005 08:20:13 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 15 Apr 2005 08:20:07 -0400 Received: from [10.82.226.12] ([10.82.226.12]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 15 Apr 2005 08:20:07 -0400 User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <7A3E36B3528ED04A880178D337F30C9A044F6285@zrc2hxm1.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Apr 2005 12:20:07.0258 (UTC) FILETIME=[75E253A0:01C541B5] Message-ID: <425FB173.8010105@cisco.com> Date: Fri, 15 Apr 2005 08:20:03 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: OSPF LSID with vary length masks To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <7A3E36B3528ED04A880178D337F30C9A044F6285@zrc2hxm1.corp.nortel.com> Precedence: list Content-Transfer-Encoding: 7bit Hi Zhao-Yang, Added subject. See inline. Zhao-Yang Dong wrote: >In an OSPF link state database, each LSA is supposed to have a unique Link >State ID (LSID). Sometimes this is not true, especially in multiple vendor >devices environment. > > > >When originating summary and/or AS-external LSAs, how to assign unique LSID >for a network number who has multiple (different length of) masks is >described in RFC 2328 appendix E. However, I did not see any discussion in >RFC 2328 nor this archive how to handle/process summary and/or AS-external >LSAs received from other routers with the same LSID but different length of >masks. > > > >According RFC 2328, a LSA is identified by LS type, LSID and advertising >router. To determine which LSA of two LSA instances is newer, LS sequence >number, checksum and age are compared. Network mask does not seem play any >role while processing the received LSAs. > > > >My question is, for example, if I received a LSA with LSID=A.B.C.D and 24 >bits mask and installed in my database, and later I received the same LSA >(i.e. same LS type, LSID and advertising router) but with 28 bits mask. If >the second LSA has the larger sequence number, should I replace my database >copy with the second LSA? > > Yes. As you noted above the LSA payload is not used to determine which LSA is newer (other than it's contribution to the LSA checksum). Of course, you will need to run an incremental (or partial depending on your terminology) for both the new LSA and the prefix corresponding to the old LSA with the different mask. Hope this helps, Acee > > >Thanks, > >Zhaoyang > > > > > > From owner-ospf@PEACH.EASE.LSOFT.COM Fri Apr 15 09:03: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 JAA27984 for ; Fri, 15 Apr 2005 09:03:30 -0400 (EDT) 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.01014EE0@cherry.ease.lsoft.com>; Fri, 15 Apr 2005 9:03:29 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 66701072 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 15 Apr 2005 09:03:27 -0400 Received: from 64.102.122.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 15 Apr 2005 09:03:27 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 15 Apr 2005 09:13:36 -0400 X-IronPort-AV: i="3.92,104,1112587200"; d="scan'208"; a="44736364:sNHT28874524" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j3FD3BRe009589 for ; Fri, 15 Apr 2005 09:03:25 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 15 Apr 2005 09:03:23 -0400 Received: from [10.82.226.12] ([10.82.226.12]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 15 Apr 2005 09:03:23 -0400 User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <7A3E36B3528ED04A880178D337F30C9A044F6285@zrc2hxm1.corp.nortel.com> <3a414d026ebf930c4160d09a978134ad@juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Apr 2005 13:03:23.0402 (UTC) FILETIME=[814E76A0:01C541BB] Message-ID: <425FBB9D.90708@cisco.com> Date: Fri, 15 Apr 2005 09:03:25 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: LSIDs with vary length masks To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <3a414d026ebf930c4160d09a978134ad@juniper.net> Precedence: list Content-Transfer-Encoding: 7bit Hi Dave, Thanks for the detailed response. I've added my hastily typed and grammatically incorrect subject for the archives. See one response inline. Dave Katz wrote: > On Apr 14, 2005, at 4:31 PM, Zhao-Yang Dong wrote: > >> In an OSPF link state database, each LSA is supposed to have a unique >> Link State ID (LSID). Sometimes this is not true, especially in >> multiple vendor devices environment. > > > The LSA ID is qualified by the originating system, so it is entirely > reasonable to have multiple LSAs with the same LSA ID but different > router IDs. > > What is *not* allowed is to have multiple LSAs with the same LSA ID > originated by the same system. This cannot happen according to the > rules, and they will not be propagated if they were, also according to > the rules. Whether there are multiple vendors has no impact on this. > >> When originating summary and/or AS-external LSAs, how to assign >> unique LSID for a network number who has multiple (different length >> of) masks is described in RFC 2328 appendix E. However, I did not see >> any discussion in RFC 2328 nor this archive how to handle/process >> summary and/or AS-external LSAs received from other routers with the >> same LSID but different length of masks. > > > A router can do anything it wants to guarantee LSA ID uniqueness on > the LSAs it generates; appendix E is one way (though there are ways > that will go further before they fail than the one outlined there.) > Note that RFC2328 also refers to appendix E for Summary LSAs as well; > see appendix A.4.5. > > It is not the job of a receiving router to deal with this case, > because it cannot happen (according to the rules) and it is > indistinguishable from the case where somebody changes the netmask on > a redistributed static route. > >> >> >> >> According RFC 2328, a LSA is identified by LS type, LSID and >> advertising router. To determine which LSA of two LSA instances is >> newer, LS sequence number, checksum and age are compared. Network >> mask does not seem play any role while processing the received LSAs. > > > It does not, nor should it. An LSA is identified by originating > router ID, LSA type, and LSA ID. Period. Any router that attempts to > generate two different LSAs with the same ID is broken. > >> >> >> >> My question is, for example, if I received a LSA with LSID=A.B.C.D >> and 24 bits mask and installed in my database, and later I received >> the same LSA (i.e. same LS type, LSID and advertising router) but >> with 28 bits mask. If the second LSA has the larger sequence number, >> should I replace my database copy with the second LSA? > > > That's what the rules say. This is why a broken system generating > multiple LSAs with the same ID will not get far; only one of them > (with the higher sequence number) will get acknowledged, and the other > will be retransmitted ad infinitum. > > > The problem is that the Founding Fathers that spec'ed OSPF screwed up > and overloaded the LSA ID with routing information because they were > afraid of spending another four bytes per LSA. One could blame it on > classful networking, but in a purely classful environment you wouldn't > even need masks. Basically it was yet another mistaken optimization. > > It's impossible to guarantee uniqueness; if you try hard enough you > can generate a situation that no algorithm can work around (because > the LSA ID space is by definition sparse due to the masking > requirement, but the space of possible external routes is dense.) As > a practical matter, however, it's very unlikely that there will be an > LSA ID collision if a reasonably good algorithm is chosen. > > > BTW, the cisco IOS implementation appears to attempt to detect this > case, though it's not clear why. I assume it complains if it sees the > same LSA ID and a different netmask, but that's a perfectly legal > situation. If anybody from cisco can explain this, I'm quite curious. A warning message will only be generated when the originating router encounters an LSA advertisement conflict that cannot be resolved using the algorithm in RFC 2328 Appendix E. This is to let the network administrator know that the conflict exists and not all prefixes are advertised. Thanks, Acee > > --Dave > > >> >> >> >> Thanks, >> >> Zhaoyang >> >> > > From owner-ospf@PEACH.EASE.LSOFT.COM Fri Apr 15 09:33:23 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 JAA00097 for ; Fri, 15 Apr 2005 09:33:23 -0400 (EDT) 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.01015032@cherry.ease.lsoft.com>; Fri, 15 Apr 2005 9:33:22 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 66704592 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 15 Apr 2005 09:33:20 -0400 Received: from 64.102.122.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 15 Apr 2005 09:33:20 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 15 Apr 2005 09:33:21 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j3FDXIRQ017183 for ; Fri, 15 Apr 2005 09:33:18 -0400 (EDT) Received: from xfe-rtp-212.amer.cisco.com ([64.102.31.100]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 15 Apr 2005 09:33:17 -0400 Received: from [10.82.226.12] ([10.82.226.12]) by xfe-rtp-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 15 Apr 2005 09:33:17 -0400 User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <7A3E36B3528ED04A880178D337F30C9A044F6285@zrc2hxm1.corp.nortel.com> <3a414d026ebf930c4160d09a978134ad@juniper.net> <01d001c5419c$bd05ba60$0601a8c0@pc6> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Apr 2005 13:33:17.0585 (UTC) FILETIME=[AEB91010:01C541BF] Message-ID: <425FC29A.8090005@cisco.com> Date: Fri, 15 Apr 2005 09:33:14 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: OSPF LSID with vary length masks To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <01d001c5419c$bd05ba60$0601a8c0@pc6> Precedence: list Content-Transfer-Encoding: 7bit Tom Petch wrote: >Agree with everything Dave saids but would stress that OSPF by design does not >cater for overlapping prefix (from the same router) so a router MUST NOT >originate two LSA, one a /24 and the other a /28 for the same prefix. Other >routing protocols are different which is an issue when redistributing from them >into OSPF. > > Hi Tom, Actually the algorithm in RFC 2328 appendix E handles the situation aboved quite nicely. For example, if you want to advertise 10.1.1.0/24 and 10.1.1.0/28 the LSIDs 10.1.1.0 and 10.1.1.15 will be used. The cases it doesn't handle are the more pathological ones. For example, say you now also want to advertise 10.1.1.8/28 and 10.1.1.8/29. You'll get a conflict since you'll try and use the LSID 10.1.1.15 for both 10.1.1.0/28 and 10.1.1.8/28. A more common conflict would be if you happen to also want to advertise the host route 10.1.1.15. Thanks, Acee >Tom Petch > >----- Original Message ----- >From: "Dave Katz" >To: >Sent: Friday, April 15, 2005 7:26 AM > > >On Apr 14, 2005, at 4:31 PM, Zhao-Yang Dong wrote: > > > >>In an OSPF link state database, each LSA is supposed to have a unique >>Link State ID (LSID). Sometimes this is not true, especially in >>multiple vendor devices environment. >> >> > >The LSA ID is qualified by the originating system, so it is entirely >reasonable to have multiple LSAs with the same LSA ID but different >router IDs. > >What is *not* allowed is to have multiple LSAs with the same LSA ID >originated by the same system. This cannot happen according to the >rules, and they will not be propagated if they were, also according to >the rules. Whether there are multiple vendors has no impact on this. > > > >>When originating summary and/or AS-external LSAs, how to assign unique >>LSID for a network number who has multiple (different length of) masks >>is described in RFC 2328 appendix E. However, I did not see any >>discussion in RFC 2328 nor this archive how to handle/process summary >>and/or AS-external LSAs received from other routers with the same LSID >>but different length of masks. >> >> > >A router can do anything it wants to guarantee LSA ID uniqueness on the >LSAs it generates; appendix E is one way (though there are ways that >will go further before they fail than the one outlined there.) Note >that RFC2328 also refers to appendix E for Summary LSAs as well; see >appendix A.4.5. > >It is not the job of a receiving router to deal with this case, because >it cannot happen (according to the rules) and it is indistinguishable >from the case where somebody changes the netmask on a redistributed >static route. > > > >> >>According RFC 2328, a LSA is identified by LS type, LSID and >>advertising router. To determine which LSA of two LSA instances is >>newer, LS sequence number, checksum and age are compared. Network mask >>does not seem play any role while processing the received LSAs. >> >> > >It does not, nor should it. An LSA is identified by originating router >ID, LSA type, and LSA ID. Period. Any router that attempts to >generate two different LSAs with the same ID is broken. > > > >> >>My question is, for example, if I received a LSA with LSID=A.B.C.D and >>24 bits mask and installed in my database, and later I received the >>same LSA (i.e. same LS type, LSID and advertising router) but with 28 >>bits mask. If the second LSA has the larger sequence number, should I >>replace my database copy with the second LSA? >> >> > >That's what the rules say. This is why a broken system generating >multiple LSAs with the same ID will not get far; only one of them >(with the higher sequence number) will get acknowledged, and the other >will be retransmitted ad infinitum. > > >The problem is that the Founding Fathers that spec'ed OSPF screwed up >and overloaded the LSA ID with routing information because they were >afraid of spending another four bytes per LSA. One could blame it on >classful networking, but in a purely classful environment you wouldn't >even need masks. Basically it was yet another mistaken optimization. > >It's impossible to guarantee uniqueness; if you try hard enough you >can generate a situation that no algorithm can work around (because the >LSA ID space is by definition sparse due to the masking requirement, >but the space of possible external routes is dense.) As a practical >matter, however, it's very unlikely that there will be an LSA ID >collision if a reasonably good algorithm is chosen. > > >BTW, the cisco IOS implementation appears to attempt to detect this >case, though it's not clear why. I assume it complains if it sees the >same LSA ID and a different netmask, but that's a perfectly legal >situation. If anybody from cisco can explain this, I'm quite curious. > >--Dave > > > > >> >>Thanks, >> >>Zhaoyang >> >> >> >> > > > From owner-ospf@PEACH.EASE.LSOFT.COM Fri Apr 15 12:14: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 MAA17656 for ; Fri, 15 Apr 2005 12:14:05 -0400 (EDT) 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.0101516D@cherry.ease.lsoft.com>; Fri, 15 Apr 2005 11:42:50 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 66715289 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 15 Apr 2005 11:42:47 -0400 Received: from 171.71.176.72 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 15 Apr 2005 11:42:47 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by sj-iport-3.cisco.com with ESMTP; 15 Apr 2005 08:42:23 -0700 X-IronPort-AV: i="3.92,105,1112598000"; d="scan'208"; a="250183304:sNHT1472889478" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j3FFfceL013500 for ; Fri, 15 Apr 2005 11:42:20 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 15 Apr 2005 11:42:04 -0400 Received: from [64.102.199.123] ([64.102.199.123]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 15 Apr 2005 11:42:04 -0400 User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <7A3E36B3528ED04A880178D337F30C9A044F6285@zrc2hxm1.corp.nortel.com> <3a414d026ebf930c4160d09a978134ad@juniper.net> <01d001c5419c$bd05ba60$0601a8c0@pc6> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Apr 2005 15:42:04.0246 (UTC) FILETIME=[AC2BF760:01C541D1] Message-ID: <425FE0CB.40102@cisco.com> Date: Fri, 15 Apr 2005 11:42:03 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: OSPF LSID with vary length masks To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <01d001c5419c$bd05ba60$0601a8c0@pc6> Precedence: list Content-Transfer-Encoding: 7bit Corrected prefix lengths in example. Tom Petch wrote: >Agree with everything Dave saids but would stress that OSPF by design does not >cater for overlapping prefix (from the same router) so a router MUST NOT >originate two LSA, one a /24 and the other a /28 for the same prefix. Other >routing protocols are different which is an issue when redistributing from them >into OSPF. > > Hi Tom, Actually the algorithm in RFC 2328 appendix E handles the situation above quite nicely. For example, if you want to advertise 10.1.1.0/24 and 10.1.1.0/28 the LSIDs 10.1.1.0 and 10.1.1.15 will be used. The cases it doesn't handle are the more pathological ones. For example, say you now also want to advertise 10.1.1.8/29 and 10.1.1.8/30. You'll get a conflict since you'll try and use the LSID 10.1.1.15 for both 10.1.1.0/28 and 10.1.1.8/30. A more common conflict would be if you happen to also want to advertise the host route 10.1.1.15/32. Thanks, Acee >Tom Petch > >----- Original Message ----- >From: "Dave Katz" >To: >Sent: Friday, April 15, 2005 7:26 AM > > >On Apr 14, 2005, at 4:31 PM, Zhao-Yang Dong wrote: > > > >>In an OSPF link state database, each LSA is supposed to have a unique >>Link State ID (LSID). Sometimes this is not true, especially in >>multiple vendor devices environment. >> >> > >The LSA ID is qualified by the originating system, so it is entirely >reasonable to have multiple LSAs with the same LSA ID but different >router IDs. > >What is *not* allowed is to have multiple LSAs with the same LSA ID >originated by the same system. This cannot happen according to the >rules, and they will not be propagated if they were, also according to >the rules. Whether there are multiple vendors has no impact on this. > > > >>When originating summary and/or AS-external LSAs, how to assign unique >>LSID for a network number who has multiple (different length of) masks >>is described in RFC 2328 appendix E. However, I did not see any >>discussion in RFC 2328 nor this archive how to handle/process summary >>and/or AS-external LSAs received from other routers with the same LSID >>but different length of masks. >> >> > >A router can do anything it wants to guarantee LSA ID uniqueness on the >LSAs it generates; appendix E is one way (though there are ways that >will go further before they fail than the one outlined there.) Note >that RFC2328 also refers to appendix E for Summary LSAs as well; see >appendix A.4.5. > >It is not the job of a receiving router to deal with this case, because >it cannot happen (according to the rules) and it is indistinguishable >from the case where somebody changes the netmask on a redistributed >static route. > > > >> >>According RFC 2328, a LSA is identified by LS type, LSID and >>advertising router. To determine which LSA of two LSA instances is >>newer, LS sequence number, checksum and age are compared. Network mask >>does not seem play any role while processing the received LSAs. >> >> > >It does not, nor should it. An LSA is identified by originating router >ID, LSA type, and LSA ID. Period. Any router that attempts to >generate two different LSAs with the same ID is broken. > > > >> >>My question is, for example, if I received a LSA with LSID=A.B.C.D and >>24 bits mask and installed in my database, and later I received the >>same LSA (i.e. same LS type, LSID and advertising router) but with 28 >>bits mask. If the second LSA has the larger sequence number, should I >>replace my database copy with the second LSA? >> >> > >That's what the rules say. This is why a broken system generating >multiple LSAs with the same ID will not get far; only one of them >(with the higher sequence number) will get acknowledged, and the other >will be retransmitted ad infinitum. > > >The problem is that the Founding Fathers that spec'ed OSPF screwed up >and overloaded the LSA ID with routing information because they were >afraid of spending another four bytes per LSA. One could blame it on >classful networking, but in a purely classful environment you wouldn't >even need masks. Basically it was yet another mistaken optimization. > >It's impossible to guarantee uniqueness; if you try hard enough you >can generate a situation that no algorithm can work around (because the >LSA ID space is by definition sparse due to the masking requirement, >but the space of possible external routes is dense.) As a practical >matter, however, it's very unlikely that there will be an LSA ID >collision if a reasonably good algorithm is chosen. > > >BTW, the cisco IOS implementation appears to attempt to detect this >case, though it's not clear why. I assume it complains if it sees the >same LSA ID and a different netmask, but that's a perfectly legal >situation. If anybody from cisco can explain this, I'm quite curious. > >--Dave > > > > >> >>Thanks, >> >>Zhaoyang >> >> >> >> > > > From owner-ospf@PEACH.EASE.LSOFT.COM Fri Apr 15 12:32: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 MAA19294 for ; Fri, 15 Apr 2005 12:32:07 -0400 (EDT) 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.010152F9@cherry.ease.lsoft.com>; Fri, 15 Apr 2005 12:32:08 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 66729963 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 15 Apr 2005 12:32:05 -0400 Received: from 47.140.192.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 15 Apr 2005 12:32:05 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j3FGW4F19205 for ; Fri, 15 Apr 2005 12:32:04 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id <2KL18CSJ>; Fri, 15 Apr 2005 12:32:03 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C541D8.A08A427E" Message-ID: <7A3E36B3528ED04A880178D337F30C9A044F6A16@zrc2hxm1.corp.nortel.com> Date: Fri, 15 Apr 2005 12:31:50 -0400 Reply-To: Mailing List Sender: Mailing List From: Zhao-Yang Dong Subject: Re: OSPF LSID with vary length masks To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C541D8.A08A427E Content-Type: text/plain Thanks guys for the quick response, I know what I am going to do about the LSAs with the duplicate LSID. The two LSAs that I mentioned in the example were both from the same third party device: LSA 1: LsType= 5, LSID=203.177.61.15, mask=255.255.255.240, advRtr=10.235.62.11, seq=0x80000001. LSA 2: LsType= 5, LSID=203.177.61.15, mask=255.255.255.255, advRtr=10.235.62.11, seq=0x80000002. It is also observed that both Cisco and Juniper routers in that network replaced LSA 1 with LSA 2 in their database. Thanks again, Zhaoyang -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Acee Lindem Sent: Friday, April 15, 2005 9:42 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: OSPF LSID with vary length masks Corrected prefix lengths in example. Tom Petch wrote: >Agree with everything Dave saids but would stress that OSPF by design does not >cater for overlapping prefix (from the same router) so a router MUST NOT >originate two LSA, one a /24 and the other a /28 for the same prefix. Other >routing protocols are different which is an issue when redistributing from them >into OSPF. > > Hi Tom, Actually the algorithm in RFC 2328 appendix E handles the situation above quite nicely. For example, if you want to advertise 10.1.1.0/24 and 10.1.1.0/28 the LSIDs 10.1.1.0 and 10.1.1.15 will be used. The cases it doesn't handle are the more pathological ones. For example, say you now also want to advertise 10.1.1.8/29 and 10.1.1.8/30. You'll get a conflict since you'll try and use the LSID 10.1.1.15 for both 10.1.1.0/28 and 10.1.1.8/30. A more common conflict would be if you happen to also want to advertise the host route 10.1.1.15/32. Thanks, Acee >Tom Petch > >----- Original Message ----- >From: "Dave Katz" >To: >Sent: Friday, April 15, 2005 7:26 AM > > >On Apr 14, 2005, at 4:31 PM, Zhao-Yang Dong wrote: > > > >>In an OSPF link state database, each LSA is supposed to have a unique >>Link State ID (LSID). Sometimes this is not true, especially in >>multiple vendor devices environment. >> >> > >The LSA ID is qualified by the originating system, so it is entirely >reasonable to have multiple LSAs with the same LSA ID but different >router IDs. > >What is *not* allowed is to have multiple LSAs with the same LSA ID >originated by the same system. This cannot happen according to the >rules, and they will not be propagated if they were, also according to >the rules. Whether there are multiple vendors has no impact on this. > > > >>When originating summary and/or AS-external LSAs, how to assign unique >>LSID for a network number who has multiple (different length of) masks >>is described in RFC 2328 appendix E. However, I did not see any >>discussion in RFC 2328 nor this archive how to handle/process summary >>and/or AS-external LSAs received from other routers with the same LSID >>but different length of masks. >> >> > >A router can do anything it wants to guarantee LSA ID uniqueness on the >LSAs it generates; appendix E is one way (though there are ways that >will go further before they fail than the one outlined there.) Note >that RFC2328 also refers to appendix E for Summary LSAs as well; see >appendix A.4.5. > >It is not the job of a receiving router to deal with this case, because >it cannot happen (according to the rules) and it is indistinguishable >from the case where somebody changes the netmask on a redistributed >static route. > > > >> >>According RFC 2328, a LSA is identified by LS type, LSID and >>advertising router. To determine which LSA of two LSA instances is >>newer, LS sequence number, checksum and age are compared. Network mask >>does not seem play any role while processing the received LSAs. >> >> > >It does not, nor should it. An LSA is identified by originating router >ID, LSA type, and LSA ID. Period. Any router that attempts to >generate two different LSAs with the same ID is broken. > > > >> >>My question is, for example, if I received a LSA with LSID=A.B.C.D and >>24 bits mask and installed in my database, and later I received the >>same LSA (i.e. same LS type, LSID and advertising router) but with 28 >>bits mask. If the second LSA has the larger sequence number, should I >>replace my database copy with the second LSA? >> >> > >That's what the rules say. This is why a broken system generating >multiple LSAs with the same ID will not get far; only one of them >(with the higher sequence number) will get acknowledged, and the other >will be retransmitted ad infinitum. > > >The problem is that the Founding Fathers that spec'ed OSPF screwed up >and overloaded the LSA ID with routing information because they were >afraid of spending another four bytes per LSA. One could blame it on >classful networking, but in a purely classful environment you wouldn't >even need masks. Basically it was yet another mistaken optimization. > >It's impossible to guarantee uniqueness; if you try hard enough you >can generate a situation that no algorithm can work around (because the >LSA ID space is by definition sparse due to the masking requirement, >but the space of possible external routes is dense.) As a practical >matter, however, it's very unlikely that there will be an LSA ID >collision if a reasonably good algorithm is chosen. > > >BTW, the cisco IOS implementation appears to attempt to detect this >case, though it's not clear why. I assume it complains if it sees the >same LSA ID and a different netmask, but that's a perfectly legal >situation. If anybody from cisco can explain this, I'm quite curious. > >--Dave > > > > >> >>Thanks, >> >>Zhaoyang >> >> >> >> > > > ------_=_NextPart_001_01C541D8.A08A427E Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: OSPF LSID with vary length masks

Thanks guys for the quick response, I know what I am = going to do about the LSAs with the duplicate LSID.

The two LSAs that I mentioned in the example were = both from the same third party device:
LSA 1: LsType=3D 5, LSID=3D203.177.61.15, = mask=3D255.255.255.240, advRtr=3D10.235.62.11, seq=3D0x80000001.
LSA 2: LsType=3D 5, LSID=3D203.177.61.15, = mask=3D255.255.255.255, advRtr=3D10.235.62.11, seq=3D0x80000002.

It is also observed that both Cisco and Juniper = routers in that network replaced LSA 1 with LSA 2 in their database. =

Thanks again,

Zhaoyang


-----Original Message-----
From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.C= OM] On Behalf Of Acee Lindem
Sent: Friday, April 15, 2005 9:42 AM
To: OSPF@PEACH.EASE.LSOFT.COM
Subject: Re: OSPF LSID with vary length masks

Corrected prefix lengths in example.

Tom Petch wrote:

>Agree with everything Dave saids but would stress = that OSPF by design does not
>cater for overlapping prefix (from the same = router) so a router MUST NOT
>originate two LSA, one a /24 and the other a /28 = for the same prefix.  Other
>routing protocols are different which is an = issue when redistributing from them
>into OSPF.
> 
>
Hi Tom,
Actually the algorithm in RFC 2328 appendix E = handles the situation
above quite nicely. For example, if you want to = advertise 10.1.1.0/24
and 10.1.1.0/28 the LSIDs 10.1.1.0 and 10.1.1.15 = will be used. The cases
it doesn't handle are the more pathological ones. = For example, say
you now also want to advertise 10.1.1.8/29 and = 10.1.1.8/30. You'll get
a conflict since you'll try and use the LSID = 10.1.1.15 for both
10.1.1.0/28 and 10.1.1.8/30. A more common conflict = would be if you
happen to also want to advertise the host route = 10.1.1.15/32.

Thanks,
Acee



>Tom Petch
>
>----- Original Message -----
>From: "Dave Katz" = <dkatz@JUNIPER.NET>
>To: <OSPF@PEACH.EASE.LSOFT.COM>
>Sent: Friday, April 15, 2005 7:26 AM
>
>
>On Apr 14, 2005, at 4:31 PM, Zhao-Yang Dong = wrote:
>
> 
>
>>In an OSPF link state database, each LSA is = supposed to have a unique
>>Link State ID (LSID). Sometimes this is not = true, especially in
>>multiple vendor devices environment.
>>   
>>
>
>The LSA ID is qualified by the originating = system, so it is entirely
>reasonable to have multiple LSAs with the same = LSA ID but different
>router IDs.
>
>What is *not* allowed is to have multiple LSAs = with the same LSA ID
>originated by the same system.  This cannot = happen according to the
>rules, and they will not be propagated if they = were, also according to
>the rules.  Whether there are multiple = vendors has no impact on this.
>
> 
>
>>When originating summary and/or AS-external = LSAs, how to assign unique
>>LSID for a network number who has multiple = (different length of) masks
>>is described in RFC 2328 appendix E. = However, I did not see any
>>discussion in RFC 2328 nor this archive how = to handle/process summary
>>and/or AS-external LSAs received from other = routers with the same LSID
>>but different length of masks.
>>   
>>
>
>A router can do anything it wants to guarantee = LSA ID uniqueness on the
>LSAs it generates; appendix E is one way (though = there are ways that
>will go further before they fail than the one = outlined there.)  Note
>that RFC2328 also refers to appendix E for = Summary LSAs as well;  see
>appendix A.4.5.
>
>It is not the job of a receiving router to deal = with this case, because
>it cannot happen (according to the rules) and it = is indistinguishable
>from the case where somebody changes the netmask = on a redistributed
>static route.
>
> 
>
>>
>>According RFC 2328, a LSA is identified by = LS type, LSID and
>>advertising router. To determine which LSA = of two LSA instances is
>>newer, LS sequence number, checksum and age = are compared. Network mask
>>does not seem play any role while processing = the received LSAs.
>>   
>>
>
>It does not, nor should it.  An LSA is = identified by originating router
>ID, LSA type, and LSA ID.  Period.  = Any router that attempts to
>generate two different LSAs with the same ID is = broken.
>
> 
>
>>
>>My question is, for example, if I received a = LSA with LSID=3DA.B.C.D and
>>24 bits mask and installed in my database, = and later I received the
>>same LSA (i.e. same LS type, LSID and = advertising router) but with 28
>>bits mask. If the second LSA has the larger = sequence number, should I
>>replace my database copy with the second = LSA?
>>   
>>
>
>That's what the rules say.  This is why a = broken system generating
>multiple LSAs with the same ID will not get = far;  only one of them
>(with the higher sequence number) will get = acknowledged, and the other
>will be retransmitted ad infinitum.
>
>
>The problem is that the Founding Fathers that = spec'ed OSPF screwed up
>and overloaded the LSA ID with routing = information because they were
>afraid of spending another four bytes per = LSA.  One could blame it on
>classful networking, but in a purely classful = environment you wouldn't
>even need masks.  Basically it was yet = another mistaken optimization.
>
>It's impossible to guarantee uniqueness;  = if you try hard enough you
>can generate a situation that no algorithm can = work around (because the
>LSA ID space is by definition sparse due to the = masking requirement,
>but the space of possible external routes is = dense.)  As a practical
>matter, however, it's very unlikely that there = will be an LSA ID
>collision if a reasonably good algorithm is = chosen.
>
>
>BTW, the cisco IOS implementation appears to = attempt to detect this
>case, though it's not clear why.  I assume = it complains if it sees the
>same LSA ID and a different netmask, but that's = a perfectly legal
>situation.  If anybody from cisco can = explain this, I'm quite curious.
>
>--Dave
>
>
> 
>
>>
>>Thanks,
>>
>>Zhaoyang
>>
>>
>>   
>>
>
> 
>

------_=_NextPart_001_01C541D8.A08A427E-- From owner-ospf@PEACH.EASE.LSOFT.COM Fri Apr 15 12:35:23 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 MAA19637 for ; Fri, 15 Apr 2005 12:35:22 -0400 (EDT) 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.01015444@cherry.ease.lsoft.com>; Fri, 15 Apr 2005 12:35:23 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 66730154 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 15 Apr 2005 12:35:21 -0400 Received: from 171.68.10.87 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 15 Apr 2005 12:35:21 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 15 Apr 2005 09:35:21 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j3FGYtbG018848 for ; Fri, 15 Apr 2005 09:35:19 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 15 Apr 2005 12:35:16 -0400 Received: from [64.102.199.123] ([64.102.199.123]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 15 Apr 2005 12:35:16 -0400 User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <7A3E36B3528ED04A880178D337F30C9A044F6285@zrc2hxm1.corp.nortel.com> <3a414d026ebf930c4160d09a978134ad@juniper.net> <01d001c5419c$bd05ba60$0601a8c0@pc6> <425FE0CB.40102@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Apr 2005 16:35:16.0795 (UTC) FILETIME=[1B1448B0:01C541D9] Message-ID: <425FED44.4020009@cisco.com> Date: Fri, 15 Apr 2005 12:35:16 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: OSPF LSID with vary length masks To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <425FE0CB.40102@cisco.com> Precedence: list Content-Transfer-Encoding: 7bit Sigh - I guess I choose a bad example. The conflict with the host route 10.1.1.15 would be the most common conflict. I've seen this in environments with subscriber routes. Acee Lindem wrote: > Corrected prefix lengths in example. > > Tom Petch wrote: > >> Agree with everything Dave saids but would stress that OSPF by design >> does not >> cater for overlapping prefix (from the same router) so a router MUST NOT >> originate two LSA, one a /24 and the other a /28 for the same >> prefix. Other >> routing protocols are different which is an issue when redistributing >> from them >> into OSPF. >> >> > Hi Tom, > Actually the algorithm in RFC 2328 appendix E handles the situation > above quite nicely. For example, if you want to advertise 10.1.1.0/24 > and 10.1.1.0/28 the LSIDs 10.1.1.0 and 10.1.1.15 will be used. The cases > it doesn't handle are the more pathological ones. For example, say > you now also want to advertise 10.1.1.8/29 and 10.1.1.8/30. You'll get > a conflict since you'll try and use the LSID 10.1.1.15 for both > 10.1.1.0/28 and 10.1.1.8/30. A more common conflict would be if you > happen to also want to advertise the host route 10.1.1.15/32. > > Thanks, > Acee > > > >> Tom Petch >> >> ----- Original Message ----- >> From: "Dave Katz" >> To: >> Sent: Friday, April 15, 2005 7:26 AM >> >> >> On Apr 14, 2005, at 4:31 PM, Zhao-Yang Dong wrote: >> >> >> >>> In an OSPF link state database, each LSA is supposed to have a unique >>> Link State ID (LSID). Sometimes this is not true, especially in >>> multiple vendor devices environment. >>> >> >> >> The LSA ID is qualified by the originating system, so it is entirely >> reasonable to have multiple LSAs with the same LSA ID but different >> router IDs. >> >> What is *not* allowed is to have multiple LSAs with the same LSA ID >> originated by the same system. This cannot happen according to the >> rules, and they will not be propagated if they were, also according to >> the rules. Whether there are multiple vendors has no impact on this. >> >> >> >>> When originating summary and/or AS-external LSAs, how to assign unique >>> LSID for a network number who has multiple (different length of) masks >>> is described in RFC 2328 appendix E. However, I did not see any >>> discussion in RFC 2328 nor this archive how to handle/process summary >>> and/or AS-external LSAs received from other routers with the same LSID >>> but different length of masks. >>> >> >> >> A router can do anything it wants to guarantee LSA ID uniqueness on the >> LSAs it generates; appendix E is one way (though there are ways that >> will go further before they fail than the one outlined there.) Note >> that RFC2328 also refers to appendix E for Summary LSAs as well; see >> appendix A.4.5. >> >> It is not the job of a receiving router to deal with this case, because >> it cannot happen (according to the rules) and it is indistinguishable >> from the case where somebody changes the netmask on a redistributed >> static route. >> >> >> >>> >>> According RFC 2328, a LSA is identified by LS type, LSID and >>> advertising router. To determine which LSA of two LSA instances is >>> newer, LS sequence number, checksum and age are compared. Network mask >>> does not seem play any role while processing the received LSAs. >>> >> >> >> It does not, nor should it. An LSA is identified by originating router >> ID, LSA type, and LSA ID. Period. Any router that attempts to >> generate two different LSAs with the same ID is broken. >> >> >> >>> >>> My question is, for example, if I received a LSA with LSID=A.B.C.D and >>> 24 bits mask and installed in my database, and later I received the >>> same LSA (i.e. same LS type, LSID and advertising router) but with 28 >>> bits mask. If the second LSA has the larger sequence number, should I >>> replace my database copy with the second LSA? >>> >> >> >> That's what the rules say. This is why a broken system generating >> multiple LSAs with the same ID will not get far; only one of them >> (with the higher sequence number) will get acknowledged, and the other >> will be retransmitted ad infinitum. >> >> >> The problem is that the Founding Fathers that spec'ed OSPF screwed up >> and overloaded the LSA ID with routing information because they were >> afraid of spending another four bytes per LSA. One could blame it on >> classful networking, but in a purely classful environment you wouldn't >> even need masks. Basically it was yet another mistaken optimization. >> >> It's impossible to guarantee uniqueness; if you try hard enough you >> can generate a situation that no algorithm can work around (because the >> LSA ID space is by definition sparse due to the masking requirement, >> but the space of possible external routes is dense.) As a practical >> matter, however, it's very unlikely that there will be an LSA ID >> collision if a reasonably good algorithm is chosen. >> >> >> BTW, the cisco IOS implementation appears to attempt to detect this >> case, though it's not clear why. I assume it complains if it sees the >> same LSA ID and a different netmask, but that's a perfectly legal >> situation. If anybody from cisco can explain this, I'm quite curious. >> >> --Dave >> >> >> >> >>> >>> Thanks, >>> >>> Zhaoyang >>> >>> >>> >> >> >> >> > > > From owner-ospf@PEACH.EASE.LSOFT.COM Fri Apr 15 12:49: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 MAA20712 for ; Fri, 15 Apr 2005 12:49:18 -0400 (EDT) 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.010152CD@cherry.ease.lsoft.com>; Fri, 15 Apr 2005 12:49:18 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 66731010 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 15 Apr 2005 12:49:13 -0400 Received: from 64.102.122.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 15 Apr 2005 12:49:11 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 15 Apr 2005 12:58:59 -0400 X-IronPort-AV: i="3.92,105,1112587200"; d="scan'208"; a="44769182:sNHT63059545168" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j3FGmkRQ015115 for ; Fri, 15 Apr 2005 12:48:47 -0400 (EDT) Received: from xfe-rtp-212.amer.cisco.com ([64.102.31.100]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 15 Apr 2005 12:48:46 -0400 Received: from [64.102.199.123] ([64.102.199.123]) by xfe-rtp-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 15 Apr 2005 12:48:45 -0400 User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <7A3E36B3528ED04A880178D337F30C9A044F6A16@zrc2hxm1.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Apr 2005 16:48:45.0923 (UTC) FILETIME=[FD5B6B30:01C541DA] Message-ID: <425FF06D.2000202@cisco.com> Date: Fri, 15 Apr 2005 12:48:45 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: OSPF LSID with vary length masks To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <7A3E36B3528ED04A880178D337F30C9A044F6A16@zrc2hxm1.corp.nortel.com> Precedence: list Content-Transfer-Encoding: 7bit Zhao-Yang Dong wrote: >Thanks guys for the quick response, I know what I am going to do about the >LSAs with the duplicate LSID. > >The two LSAs that I mentioned in the example were both from the same third >party device: >LSA 1: LsType= 5, LSID=203.177.61.15, mask=255.255.255.240, >advRtr=10.235.62.11, seq=0x80000001. >LSA 2: LsType= 5, LSID=203.177.61.15, mask=255.255.255.255, >advRtr=10.235.62.11, seq=0x80000002. > >It is also observed that both Cisco and Juniper routers in that network >replaced LSA 1 with LSA 2 in their database. > > This is the right thing to do as per RFC 2328. Thanks, Acee >Thanks again, > >Zhaoyang > > >-----Original Message----- >From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Acee >Lindem >Sent: Friday, April 15, 2005 9:42 AM >To: OSPF@PEACH.EASE.LSOFT.COM >Subject: Re: OSPF LSID with vary length masks > >Corrected prefix lengths in example. > >Tom Petch wrote: > > > >>Agree with everything Dave saids but would stress that OSPF by design does >> >> >not > > >>cater for overlapping prefix (from the same router) so a router MUST NOT >>originate two LSA, one a /24 and the other a /28 for the same prefix. >> >> >Other > > >>routing protocols are different which is an issue when redistributing from >> >> >them > > >>into OSPF. >> >> >> >> >Hi Tom, >Actually the algorithm in RFC 2328 appendix E handles the situation >above quite nicely. For example, if you want to advertise 10.1.1.0/24 >and 10.1.1.0/28 the LSIDs 10.1.1.0 and 10.1.1.15 will be used. The cases >it doesn't handle are the more pathological ones. For example, say >you now also want to advertise 10.1.1.8/29 and 10.1.1.8/30. You'll get >a conflict since you'll try and use the LSID 10.1.1.15 for both >10.1.1.0/28 and 10.1.1.8/30. A more common conflict would be if you >happen to also want to advertise the host route 10.1.1.15/32. > >Thanks, >Acee > > > > > >>Tom Petch >> >>----- Original Message ----- >>From: "Dave Katz" >>To: >>Sent: Friday, April 15, 2005 7:26 AM >> >> >>On Apr 14, 2005, at 4:31 PM, Zhao-Yang Dong wrote: >> >> >> >> >> >>>In an OSPF link state database, each LSA is supposed to have a unique >>>Link State ID (LSID). Sometimes this is not true, especially in >>>multiple vendor devices environment. >>> >>> >>> >>> >>The LSA ID is qualified by the originating system, so it is entirely >>reasonable to have multiple LSAs with the same LSA ID but different >>router IDs. >> >>What is *not* allowed is to have multiple LSAs with the same LSA ID >>originated by the same system. This cannot happen according to the >>rules, and they will not be propagated if they were, also according to >>the rules. Whether there are multiple vendors has no impact on this. >> >> >> >> >> >>>When originating summary and/or AS-external LSAs, how to assign unique >>>LSID for a network number who has multiple (different length of) masks >>>is described in RFC 2328 appendix E. However, I did not see any >>>discussion in RFC 2328 nor this archive how to handle/process summary >>>and/or AS-external LSAs received from other routers with the same LSID >>>but different length of masks. >>> >>> >>> >>> >>A router can do anything it wants to guarantee LSA ID uniqueness on the >>LSAs it generates; appendix E is one way (though there are ways that >>will go further before they fail than the one outlined there.) Note >>that RFC2328 also refers to appendix E for Summary LSAs as well; see >>appendix A.4.5. >> >>It is not the job of a receiving router to deal with this case, because >>it cannot happen (according to the rules) and it is indistinguishable >> >> >>from the case where somebody changes the netmask on a redistributed > > >>static route. >> >> >> >> >> >>>According RFC 2328, a LSA is identified by LS type, LSID and >>>advertising router. To determine which LSA of two LSA instances is >>>newer, LS sequence number, checksum and age are compared. Network mask >>>does not seem play any role while processing the received LSAs. >>> >>> >>> >>> >>It does not, nor should it. An LSA is identified by originating router >>ID, LSA type, and LSA ID. Period. Any router that attempts to >>generate two different LSAs with the same ID is broken. >> >> >> >> >> >>>My question is, for example, if I received a LSA with LSID=A.B.C.D and >>>24 bits mask and installed in my database, and later I received the >>>same LSA (i.e. same LS type, LSID and advertising router) but with 28 >>>bits mask. If the second LSA has the larger sequence number, should I >>>replace my database copy with the second LSA? >>> >>> >>> >>> >>That's what the rules say. This is why a broken system generating >>multiple LSAs with the same ID will not get far; only one of them >>(with the higher sequence number) will get acknowledged, and the other >>will be retransmitted ad infinitum. >> >> >>The problem is that the Founding Fathers that spec'ed OSPF screwed up >>and overloaded the LSA ID with routing information because they were >>afraid of spending another four bytes per LSA. One could blame it on >>classful networking, but in a purely classful environment you wouldn't >>even need masks. Basically it was yet another mistaken optimization. >> >>It's impossible to guarantee uniqueness; if you try hard enough you >>can generate a situation that no algorithm can work around (because the >>LSA ID space is by definition sparse due to the masking requirement, >>but the space of possible external routes is dense.) As a practical >>matter, however, it's very unlikely that there will be an LSA ID >>collision if a reasonably good algorithm is chosen. >> >> >>BTW, the cisco IOS implementation appears to attempt to detect this >>case, though it's not clear why. I assume it complains if it sees the >>same LSA ID and a different netmask, but that's a perfectly legal >>situation. If anybody from cisco can explain this, I'm quite curious. >> >>--Dave >> >> >> >> >> >> >>>Thanks, >>> >>>Zhaoyang >>> >>> >>> >>> >>> >>> >> >> >> >> > > > > From owner-ospf@PEACH.EASE.LSOFT.COM Fri Apr 15 15:19:10 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 PAA06276 for ; Fri, 15 Apr 2005 15:19:10 -0400 (EDT) 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.01015727@cherry.ease.lsoft.com>; Fri, 15 Apr 2005 15:19:09 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 66742919 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 15 Apr 2005 15:19:08 -0400 Received: from 207.17.137.64 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 15 Apr 2005 15:19:08 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id j3FJJ7Bm041978 for ; Fri, 15 Apr 2005 12:19:07 -0700 (PDT) (envelope-from dkatz@juniper.net) Received: from [172.16.12.201] (nimbus-bsr.juniper.net [172.16.12.201]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j3FJJ7e27907 for ; Fri, 15 Apr 2005 12:19:07 -0700 (PDT) (envelope-from dkatz@juniper.net) Mime-Version: 1.0 (Apple Message framework v619.2) References: <7A3E36B3528ED04A880178D337F30C9A044F6285@zrc2hxm1.corp.nortel.com> <3a414d026ebf930c4160d09a978134ad@juniper.net> <01d001c5419c$bd05ba60$0601a8c0@pc6> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.619.2) Message-ID: Date: Fri, 15 Apr 2005 12:19:05 -0700 Reply-To: Mailing List Sender: Mailing List From: Dave Katz Subject: Re: Overlapping Routes To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <01d001c5419c$bd05ba60$0601a8c0@pc6> Precedence: list Content-Transfer-Encoding: 7bit On Apr 15, 2005, at 2:22 AM, Tom Petch wrote: > Agree with everything Dave saids but would stress that OSPF by design > does not > cater for overlapping prefix (from the same router) so a router MUST > NOT > originate two LSA, one a /24 and the other a /28 for the same prefix. > Other > routing protocols are different which is an issue when redistributing > from them > into OSPF. Do not confuse the encoding of the LSA IDs with the concept of advertising overlapping routes. It is perfectly reasonable to advertise overlapping routes, if not necessarily too useful. In fact, all the gorp in appendix E is to specifically support overlapping routes (because of the screwed up LSA ID encoding.) --Dave