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 From owner-ospf@PEACH.EASE.LSOFT.COM Sun Apr 17 10:56: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 KAA28585 for ; Sun, 17 Apr 2005 10:56:56 -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.01017ED1@cherry.ease.lsoft.com>; 17 Apr 2005 10:56:52 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 66935963 for OSPF@PEACH.EASE.LSOFT.COM; Sun, 17 Apr 2005 10:56:49 -0400 Received: from 130.76.32.69 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sun, 17 Apr 2005 10:56:49 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id HAA24803 for ; Sun, 17 Apr 2005 07:56:48 -0700 (PDT) Received: from xch-nwbh-01.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j3HEumN10702 for ; Sun, 17 Apr 2005 07:56:48 -0700 (PDT) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by xch-nwbh-01.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 17 Apr 2005 07:56:48 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: Working Group Last Call on "Multi-Topology (MT) Routing in OSPF" (draft-ietf-ospf-mt-03.txt) Thread-Index: AcU5Z59BWAfLlKyAQtW9uGgmcXKzlgIrvruQ X-OriginalArrivalTime: 17 Apr 2005 14:56:48.0055 (UTC) FILETIME=[AE059C70:01C5435D] Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C06649192@xch-nw-27.nw.nos.boeing.com> Date: Sun, 17 Apr 2005 07:56:47 -0700 Reply-To: Mailing List Sender: Mailing List From: "Henderson, Thomas R" Subject: Re: 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: quoted-printable I took a fresh read of this and have the following comments: Section 1: I agree with previous posters that a) some brief justification of why MT is being resurrected would be helpful in the introduction, as well as b) some text clearly distinguishing the differences between MT and 1583 TOS based routing. Section 3.3: =20 > OSPF control packets MUST be sent over the default topology. This is still not clear to me what happens with e.g., Hellos when the link is enabled for some MT-ID but disabled for the default topology. Related to this, I don't quite understand what is meant by Section 4.4. Section 3.6: > Each nexthop computed during the MT SPF MUST belong to the same MT. We (and at least one other implementer that I know of) have implemented an option that allows for this rule to be relaxed in special cases in which not all routers are upgraded simultaneously. The concern is that there may be a router somewhere in the area that can not be upgraded immediately, but is in a particular upstream location such that i) its lack of support for MT is blocking the effective use of MT downstream, and ii) the use of its default links as surrogates for MT links would not cause routing loops. It is therefore possible to implement a variant that mixes MT links and default links in the SPF computation, if a fully MT path does not exist. I propose that Section 3.6 remain as it is (because I believe that it is important to enforce the above statement for the common case), but in the transition section (Section 6), I suggest the following new paragraph be inserted at the end: "The above specification of MT routing does not allow for forwarding paths to be constructed with a mix of MT links and default links, in such cases for which a fully MT path does not exist. For the purpose of transition, it is possible to implement an option that relaxes the constraint that all links in an MT path only use MT links. Such an option, if used, MUST be applied consistently for a given MT in a routing domain (so that consistent forwarding decisions are made), and SHOULD be used with caution by operators because of its potential to enable routing loops if configured incorrectly." Section 3.7: > 1 - Reserved for advertising the metric associated with the > default multicast topology Does something more need to be said about multicast than just this brief statement? If MT-1 is not there, is the link invisible from multicast perspective? Or does it depend on the RoutingExclusion bit? Should it even be constrained in this manner (i.e., might I want to define possibly multiple multicast topologies)? =20 I would suggest to leave out MT-1 definition, since it is otherwise stated (e.g., Section 3.8) that it is outside of the scope of the document how to map packets to MTs. Section 3.8 (Forwarding in MT): The specification is ambiguous as to how to treat packets that a) map to a defined MT in the area, but b) do not have a path to the desired prefix in the MT topology, yet do have a default path there. In the 1583 TOS routing, such packets would fall back to the default topology. I would recommend that such behavior be preserved here, because it is more robust, especially in light of the new capability to exclude links from the default topology if so desired. In fact, it should be possible to define the behavior as an option; i.e., one could configure a particular MT-ID to either fallback to default or not. Therefore, I suggest the following additional paragraph in 3.8, adapting the language from 1583 Section 2.4: "It may be the case that no path exists for some MT-ID, even if the router is calculating paths for that specific MT-ID. In that case, depending on the configuration of that MT-ID, packets mapping to that MT-ID are either routed along the default topology or are dropped. Such configuration MUST be consistently applied throughout the network." Section 4.1: > The link exclusion capability requires routers to ignore TOS0 metrics in > Router-LSAs in the default topology and to alternately use the > MT-ID#0 metric to advertise the metric associated with the default > topology. Assuming that excluding links from the default would be the exception, not the common case, it would be more efficient to code this inversely as to how it is specified (links "opt out" of default rather than "opt in"). For example, if MT-ID 0 is present for a link, has a metric of 0xFFFF, and the MT-bit is set in the area, then such link is excluded from default topology. Note that this would also clear up the ambiguity as to what to put into the TOS 0 field when the default is being excluded (as was pointed out in a previous post). > The unused T-bit is defined as the MT-bit in the option field in > order to assure that a multi-topology link-excluding capable router > will only form an adjacency with another similarly configured router. Previously this bit was used to declare that TOS routing was in effect. Now, there is no such bit. If the MTRoutingExclusionCapability is disabled, then there seems to be no way for a router to tell whether its peer is MT capable, other than seeing MT metrics show up in the LSAs. Is this intended? > +---+---+---+---+---+---+---+---+ > |DN |O |DC |EA |NP |MC |E |MT | > +---+---+---+---+---+---+---+---+ > > MT-bit: This bit MUST be set in the Hello packet only if > MTRoutingExclusionCapability is enabled (see Section 4.2) The MTRoutingExclusionCapability name seems like a misnomer to me. It sounds from the name like it excludes the MT routing capability, when in fact, it is referring to Default Routing Exclusion. Suggest change to DE (DefaultExclusionCapability). Section 6: s/part of an area is upgrade/part of an area is upgraded/ Tom From owner-ospf@PEACH.EASE.LSOFT.COM Mon Apr 18 06:12:08 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 GAA03101 for ; Mon, 18 Apr 2005 06:12: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 <0.010195DF@cherry.ease.lsoft.com>; Mon, 18 Apr 2005 6:12:05 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 67006969 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 18 Apr 2005 06:12:03 -0400 Received: from 144.254.15.118 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 18 Apr 2005 06:11:59 -0400 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 j3IABwZ16610 for ; Mon, 18 Apr 2005 12:11:58 +0200 (CEST) Received: from cisco.com (dhcp-bru-peg2-vl28-144-254-0-155.cisco.com [144.254.0.155]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j3IABvK23453 for ; Mon, 18 Apr 2005 12:11:57 +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: <6938661A6EDA8A4EA8D1419BCE46F24C06649192@xch-nw-27.nw.nos.boeing.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <426387EC.8040807@cisco.com> Date: Mon, 18 Apr 2005 12:11:56 +0200 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) To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Tom, please see inline: Henderson, Thomas R wrote: > I took a fresh read of this and have the following comments: > > Section 1: > I agree with previous posters that a) some brief justification of why MT > is being resurrected would be helpful in the introduction, as well as b) > some text clearly distinguishing the differences between MT and 1583 TOS > based routing. > > Section 3.3: > >> OSPF control packets MUST be sent over the default topology. > > > This is still not clear to me what happens with e.g., Hellos when the > link is enabled for some MT-ID but disabled for the default topology. > Related to this, I don't quite understand what is meant by Section 4.4. - sending of OSPF control packets is unchanged from RFC2328 - link being enabled/disabled in the default topology only affects what is being advertised by OSPF. It does not affect installation of connected routes to the RIB that corresponds to the default topology > > Section 3.6: > >>Each nexthop computed during the MT SPF MUST belong to the same MT. > > > We (and at least one other implementer that I know of) have implemented > an option that allows for this rule to be relaxed in special cases in > which not all routers are upgraded simultaneously. The concern is that > there may be a router somewhere in the area that can not be upgraded > immediately, but is in a particular upstream location such that i) its > lack of support for MT is blocking the effective use of MT downstream, > and ii) the use of its default links as surrogates for MT links would > not cause routing loops. It is therefore possible to implement a > variant that mixes MT links and default links in the SPF computation, if > a fully MT path does not exist. > > I propose that Section 3.6 remain as it is (because I believe that it is > important to enforce the above statement for the common case), but in > the transition section (Section 6), I suggest the following new > paragraph be inserted at the end: > > "The above specification of MT routing does not allow for forwarding > paths to be constructed with a mix of MT links and default links, in > such cases for which a fully MT path does not exist. For the purpose of > transition, it is possible to implement an option that relaxes the > constraint that all links in an MT path only use MT links. Such an > option, if used, MUST be applied consistently for a given MT in a > routing domain (so that consistent forwarding decisions are made), and > SHOULD be used with caution by operators because of its potential to > enable routing loops if configured incorrectly." If some implementations give user such an option, that's fine. I'm not sure though if we want to specify this in the draft, especially if we agree that such an option can cause routing loops. > > Section 3.7: > >> 1 - Reserved for advertising the metric associated with the >> default multicast topology > > > Does something more need to be said about multicast than just this brief > statement? If MT-1 is not there, is the link invisible from multicast > perspective? Or does it depend on the RoutingExclusion bit? Should it > even be constrained in this manner (i.e., might I want to define > possibly multiple multicast topologies)? - if the link is not advertised with the MTID-1 metric, then the link does not participate in the default multicast topology - user can define multiple multicast topologies, there is no restriction - RoutingExclusion bit relates to default unicast topology only, we will make that clear in the draft > > I would suggest to leave out MT-1 definition, since it is otherwise > stated (e.g., Section 3.8) that it is outside of the scope of the > document how to map packets to MTs. - we have MTID-0 reserved for default unicast topology, we felt reserving one for base multicast topology would make sense > > Section 3.8 (Forwarding in MT): > The specification is ambiguous as to how to treat packets that a) map to > a defined MT in the area, but b) do not have a path to the desired > prefix in the MT topology, yet do have a default path there. In the > 1583 TOS routing, such packets would fall back to the default topology. > I would recommend that such behavior be preserved here, because it is > more robust, especially in light of the new capability to exclude links > from the default topology if so desired. In fact, it should be possible > to define the behavior as an option; i.e., one could configure a > particular MT-ID to either fallback to default or not. > > Therefore, I suggest the following additional paragraph in 3.8, adapting > the language from 1583 Section 2.4: > > "It may be the case that no path exists for some MT-ID, even if the > router is calculating paths for that specific MT-ID. In that case, > depending on the configuration of that MT-ID, packets mapping to that > MT-ID are either routed along the default topology or are dropped. Such > configuration MUST be consistently applied throughout the network." - one can define various forwarding behaviors with different results. As you said implementation can provide a configurable forwarding behavior. - what we specified in the draft was how OSPF should compute paths and populate topology specific RIB. I'm not sure the specification of how the forwarding entries in various RIBs/FIBs are used during the forwarding belongs to this draft. > > Section 4.1: > >> The link exclusion capability requires routers to ignore TOS0 > > metrics in > >> Router-LSAs in the default topology and to alternately use the >> MT-ID#0 metric to advertise the metric associated with the default >> topology. > > > Assuming that excluding links from the default would be the exception, > not the common case, it would be more efficient to code this inversely > as to how it is specified (links "opt out" of default rather than "opt > in"). For example, if MT-ID 0 is present for a link, has a metric of > 0xFFFF, and the MT-bit is set in the area, then such link is excluded > from default topology. Note that this would also clear up the ambiguity > as to what to put into the TOS 0 field when the default is being > excluded (as was pointed out in a previous post). - current behavior is consistent for all MTIDs (including MTID-0). If the MTID metric is not advertised, link/prefix does not participate in the given topology - 0xFFFF is a valid metric in RFC232, so we can not use it to signal unreachability. Defining 0xFFFF as unreachable metric for MTID-0 only would be ugly - with your proposal, you would have to look for two metrics during SPF as you process each link (TOS 0 and MTID-0) to be able to behave correctly - with your proposal, ambiguity problem still exist, just has been moved to a different case > > >> The unused T-bit is defined as the MT-bit in the option field in >> order to assure that a multi-topology link-excluding capable > > router > >> will only form an adjacency with another similarly configured > > router. > > Previously this bit was used to declare that TOS routing was in effect. > Now, there is no such bit. If the MTRoutingExclusionCapability is > disabled, then there seems to be no way for a router to tell whether its > peer is MT capable, other than seeing MT metrics show up in the LSAs. > Is this intended? yes. The fact that the neighbor is sending us additional metrics is harmless. > > >> +---+---+---+---+---+---+---+---+ >> |DN |O |DC |EA |NP |MC |E |MT | >> +---+---+---+---+---+---+---+---+ >> >> MT-bit: This bit MUST be set in the Hello packet only if >> MTRoutingExclusionCapability is enabled (see Section > > 4.2) > > The MTRoutingExclusionCapability name seems like a misnomer to me. It > sounds from the name like it excludes the MT routing capability, when in > fact, it is referring to Default Routing Exclusion. Suggest change to > DE (DefaultExclusionCapability). I'm fine with whatever name majority of people are happy with. > > Section 6: > s/part of an area is upgrade/part of an area is upgraded/ will be fixed. Peter > > Tom > From owner-ospf@PEACH.EASE.LSOFT.COM Mon Apr 18 14:07: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 OAA11932 for ; Mon, 18 Apr 2005 14:07: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 <13.01019AE2@cherry.ease.lsoft.com>; Mon, 18 Apr 2005 14:07:19 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 67086094 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 18 Apr 2005 14:07:17 -0400 Received: from 216.37.114.8 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 18 Apr 2005 14:07:07 -0400 Received: (qmail 14875 invoked from network); 18 Apr 2005 18:06:14 -0000 Received: from unknown (HELO ?192.168.1.28?) (172.16.104.130) by lxmail.nj.us.utstar.com with SMTP; 18 Apr 2005 18:06:14 -0000 User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.6) Gecko/20050328 Fedora/1.7.6-1.2.5 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <6938661A6EDA8A4EA8D1419BCE46F24C06649192@xch-nw-27.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <42641337.6000408@xebeo.com> Date: Mon, 18 Apr 2005 20:06:15 +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) To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C06649192@xch-nw-27.nw.nos.boeing.com> Precedence: list Content-Transfer-Encoding: 7bit Henderson, Thomas R wrote: >I took a fresh read of this and have the following comments: > > > > >We (and at least one other implementer that I know of) have implemented >an option that allows for this rule to be relaxed in special cases in >which not all routers are upgraded simultaneously. The concern is that >there may be a router somewhere in the area that can not be upgraded >immediately, but is in a particular upstream location such that i) its >lack of support for MT is blocking the effective use of MT downstream, >and ii) the use of its default links as surrogates for MT links would >not cause routing loops. It is therefore possible to implement a >variant that mixes MT links and default links in the SPF computation, if >a fully MT path does not exist. > >I propose that Section 3.6 remain as it is (because I believe that it is >important to enforce the above statement for the common case), but in >the transition section (Section 6), I suggest the following new >paragraph be inserted at the end: > >"The above specification of MT routing does not allow for forwarding >paths to be constructed with a mix of MT links and default links, in >such cases for which a fully MT path does not exist. For the purpose of >transition, it is possible to implement an option that relaxes the >constraint that all links in an MT path only use MT links. Such an >option, if used, MUST be applied consistently for a given MT in a >routing domain (so that consistent forwarding decisions are made), and >SHOULD be used with caution by operators because of its potential to >enable routing loops if configured incorrectly." > > There is a _lot_ of looping potential here from experience. I am not clear first which scenario you are pursuing. Either 1) all routers are MT aware in the deployment, then why don't you just add the necessary links to the desired MT topology and you don't need any such hacks. 2) If you desire to have some routers being non-MT capable, unless you give an exact algebra (or worded more simply, rules) that the operators must follow to avoid the loops you allure to, how is he supposed to know how to deploy your hack ? As well, you have to precisely specify the SPF algorithm you're using ? Otherwise I think including anything like that in the spec is an accident waiting to happen in terms both of interoperability and practical deployment. >Section 3.7: > > >> 1 - Reserved for advertising the metric associated with the >> default multicast topology >> >> > >Does something more need to be said about multicast than just this brief >statement? If MT-1 is not there, is the link invisible from multicast >perspective? Or does it depend on the RoutingExclusion bit? Should it >even be constrained in this manner (i.e., might I want to define >possibly multiple multicast topologies)? > >I would suggest to leave out MT-1 definition, since it is otherwise >stated (e.g., Section 3.8) that it is outside of the scope of the >document how to map packets to MTs. > >Section 3.8 (Forwarding in MT): >The specification is ambiguous as to how to treat packets that a) map to >a defined MT in the area, but b) do not have a path to the desired >prefix in the MT topology, yet do have a default path there. In the >1583 TOS routing, such packets would fall back to the default topology. > > >I would recommend that such behavior be preserved here, because it is >more robust, especially in light of the new capability to exclude links >from the default topology if so desired. In fact, it should be possible >to define the behavior as an option; i.e., one could configure a >particular MT-ID to either fallback to default or not. > > MT is _not_ TOS routing (any claim as to that is made purely to generate confusion IMO). MT is a solution to generate multiple, _independent_ topologies in the same routing protocol and not a 'special-capability link' vs. 'general-link' solution. Simply forwarding along the default path if a link lacks a MT metric will lead to routing loops very easily. Example: +------ #0/1 ----------------------->C | ^ v | A <-- #1/10 ---> B <---#0/10---------+ ^ ^ | | +-----#0/1-------+ (where #1/X denotes link in topology 1 with metric X, assume all links bidirectional with same metric, A, B and C all understand MT). If A forwards to B in topology #1 but B forwards along the shortest 'default' path you'll have a persistent loop. Now start to imagine what will happen if you start to deal with subset of routers that do not understand MT on the way. I would strongly suggest to leave anything out as to general fallback-default-topology forwarding from the spec (you're free of course attempting any little private hack you can get people to pick up) unless the implications and algorithms are very tightly written down (as footnote: there exists an algebra [and algorithm] that deals with this problem precisely [i.e. default topology being a subset of the MT topology] but it delivers non-obvious results, especially the Bellman-suboptimality doesn't hold [i.e. the resulting set of shortest-paths is not a tree] which is enough to make most people heads spin and decide they don't care about this problem all THAT much) -- tony From owner-ospf@PEACH.EASE.LSOFT.COM Mon Apr 18 16:21: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 QAA03327 for ; Mon, 18 Apr 2005 16:21: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 <19.01019CE6@cherry.ease.lsoft.com>; Mon, 18 Apr 2005 16:21:10 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 67106623 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 18 Apr 2005 16:20:59 -0400 Received: from 130.76.32.69 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 18 Apr 2005 16:20:59 -0400 Received: from stl-av-01.boeing.com ([192.76.190.6]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id NAA22927 for ; Mon, 18 Apr 2005 13:20:58 -0700 (PDT) Received: from XCH-NWBH-02.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j3IKKum14521 for ; Mon, 18 Apr 2005 15:20:57 -0500 (CDT) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 18 Apr 2005 13:19:48 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: Working Group Last Call on "Multi-Topology (MT) Routing in OSPF" (draft-ietf-ospf-mt-03.txt) Thread-Index: AcVD/xWXPaNTkXEJQSq2Qfn31IbWVQAKw8lw X-OriginalArrivalTime: 18 Apr 2005 20:19:48.0142 (UTC) FILETIME=[F7DDF4E0:01C54453] Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C0664919E@xch-nw-27.nw.nos.boeing.com> Date: Mon, 18 Apr 2005 13:19:47 -0700 Reply-To: Mailing List Sender: Mailing List From: "Henderson, Thomas R" Subject: Re: 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: quoted-printable Peter, thanks for your replies. I'll reply to the points that Tony brought up separately. Please see below:=20 =20 > > Section 3.3: =20 > >=20 > >> OSPF control packets MUST be sent over the default topology. > >=20 > >=20 > > This is still not clear to me what happens with e.g.,=20 > Hellos when the=20 > > link is enabled for some MT-ID but disabled for the default=20 > topology. > > Related to this, I don't quite understand what is meant by=20 > Section 4.4. >=20 > - sending of OSPF control packets is unchanged from RFC2328 > - link being enabled/disabled in the default topology only=20 > affects what is being advertised by OSPF. It does not affect=20 > installation of connected routes to the RIB that corresponds=20 > to the default topology I don't think that the existing text is saying the above bullets, or at least, it is possible to interpet it differently (as I apparently did). Is the following what you want to say? "Sending of OSPF control packets is unchanged from RFC2328, except in the case of sending OSPF packets across virtual links, in which case the intra-area path of the virtual link MUST only be composed of links on the default topology, and OSPF control packets being forwarded MUST be forwarded using the default topology." If so, I would suggest changing 3.3 to the above, and removing 4.4. >=20 >=20 >=20 > >=20 > > Section 3.6: > >=20 > >>Each nexthop computed during the MT SPF MUST belong to the same MT. > >=20 > >=20 > > We (and at least one other implementer that I know of) have=20 > > implemented an option that allows for this rule to be relaxed in=20 > > special cases in which not all routers are upgraded=20 > simultaneously. =20 > > The concern is that there may be a router somewhere in the=20 > area that=20 > > can not be upgraded immediately, but is in a particular upstream=20 > > location such that i) its lack of support for MT is blocking the=20 > > effective use of MT downstream, and ii) the use of its=20 > default links=20 > > as surrogates for MT links would not cause routing loops. It is=20 > > therefore possible to implement a variant that mixes MT links and=20 > > default links in the SPF computation, if a fully MT path=20 > does not exist. > >=20 > > I propose that Section 3.6 remain as it is (because I=20 > believe that it=20 > > is important to enforce the above statement for the common=20 > case), but=20 > > in the transition section (Section 6), I suggest the following new=20 > > paragraph be inserted at the end: > >=20 > > "The above specification of MT routing does not allow for=20 > forwarding=20 > > paths to be constructed with a mix of MT links and default=20 > links, in=20 > > such cases for which a fully MT path does not exist. For=20 > the purpose=20 > > of transition, it is possible to implement an option that=20 > relaxes the=20 > > constraint that all links in an MT path only use MT links. Such an=20 > > option, if used, MUST be applied consistently for a given MT in a=20 > > routing domain (so that consistent forwarding decisions are=20 > made), and=20 > > SHOULD be used with caution by operators because of its=20 > potential to=20 > > enable routing loops if configured incorrectly." >=20 > If some implementations give user such an option, that's fine. > I'm not sure though if we want to specify this in the draft,=20 > especially if we agree that such an option can cause routing loops. >=20 (reply in another message) >=20 > >=20 > > Section 3.7: > >=20 > >> 1 - Reserved for advertising the metric=20 > associated with the > >> default multicast topology > >=20 > >=20 > > Does something more need to be said about multicast than=20 > just this brief > > statement? If MT-1 is not there, is the link invisible=20 > from multicast > > perspective? Or does it depend on the RoutingExclusion=20 > bit? Should it > > even be constrained in this manner (i.e., might I want to define > > possibly multiple multicast topologies)? >=20 > - if the link is not advertised with the MTID-1 metric, then the link=20 > does not participate in the default multicast topology > - user can define multiple multicast topologies, there is no=20 > restriction > - RoutingExclusion bit relates to default unicast topology=20 > only, we will=20 > make that clear in the draft OK, with the clarification, I am fine with reserving the value. > >=20 > > Section 3.8 (Forwarding in MT): > > The specification is ambiguous as to how to treat packets=20 > that a) map to > > a defined MT in the area, but b) do not have a path to the desired > > prefix in the MT topology, yet do have a default path there. In the > > 1583 TOS routing, such packets would fall back to the=20 > default topology. > > I would recommend that such behavior be preserved here,=20 > because it is > > more robust, especially in light of the new capability to=20 > exclude links > > from the default topology if so desired. In fact, it=20 > should be possible > > to define the behavior as an option; i.e., one could configure a > > particular MT-ID to either fallback to default or not. > >=20 > > Therefore, I suggest the following additional paragraph in=20 > 3.8, adapting > > the language from 1583 Section 2.4: > >=20 > > "It may be the case that no path exists for some MT-ID, even if the > > router is calculating paths for that specific MT-ID. In that case, > > depending on the configuration of that MT-ID, packets=20 > mapping to that > > MT-ID are either routed along the default topology or are=20 > dropped. Such > > configuration MUST be consistently applied throughout the network." >=20 > - one can define various forwarding behaviors with different=20 > results. As=20 > you said implementation can provide a configurable forwarding=20 > behavior. > - what we specified in the draft was how OSPF should compute=20 > paths and=20 > populate topology specific RIB. I'm not sure the specification of how=20 > the forwarding entries in various RIBs/FIBs are used during the=20 > forwarding belongs to this draft. >=20 (reply in another message) >=20 > >=20 > > Section 4.1: > >=20 > >> The link exclusion capability requires routers to ignore TOS0 > >=20 > > metrics in > >=20 > >> Router-LSAs in the default topology and to alternately use the > >> MT-ID#0 metric to advertise the metric associated with the default > >> topology. > >=20 > >=20 > > Assuming that excluding links from the default would be the=20 > exception, > > not the common case, it would be more efficient to code=20 > this inversely > > as to how it is specified (links "opt out" of default=20 > rather than "opt > > in"). For example, if MT-ID 0 is present for a link, has a=20 > metric of > > 0xFFFF, and the MT-bit is set in the area, then such link=20 > is excluded > > from default topology. Note that this would also clear up=20 > the ambiguity > > as to what to put into the TOS 0 field when the default is being > > excluded (as was pointed out in a previous post). >=20 > - current behavior is consistent for all MTIDs (including MTID-0). If=20 > the MTID metric is not advertised, link/prefix does not=20 > participate in=20 > the given topology > - 0xFFFF is a valid metric in RFC232, so we can not use it to signal=20 > unreachability. Defining 0xFFFF as unreachable metric for MTID-0 only=20 > would be ugly > - with your proposal, you would have to look for two metrics=20 > during SPF=20 > as you process each link (TOS 0 and MTID-0) to be able to=20 > behave correctly > - with your proposal, ambiguity problem still exist, just has=20 > been moved=20 > to a different case >=20 OK, can leave this as is for consistency's sake. >=20 > >=20 > >=20 > >> The unused T-bit is defined as the MT-bit in the option field in > >> order to assure that a multi-topology link-excluding capable > >=20 > > router > >=20 > >> will only form an adjacency with another similarly configured > >=20 > > router. > >=20 > > Previously this bit was used to declare that TOS routing=20 > was in effect. > > Now, there is no such bit. If the MTRoutingExclusionCapability is > > disabled, then there seems to be no way for a router to=20 > tell whether its > > peer is MT capable, other than seeing MT metrics show up in=20 > the LSAs. > > Is this intended? >=20 > yes. The fact that the neighbor is sending us additional metrics is=20 > harmless. >=20 > >=20 > >=20 > >> +---+---+---+---+---+---+---+---+ > >> |DN |O |DC |EA |NP |MC |E |MT | > >> +---+---+---+---+---+---+---+---+ > >> > >> MT-bit: This bit MUST be set in the Hello packet only if > >> MTRoutingExclusionCapability is enabled (see Section > >=20 > > 4.2) > >=20 > > The MTRoutingExclusionCapability name seems like a misnomer=20 > to me. It > > sounds from the name like it excludes the MT routing=20 > capability, when in > > fact, it is referring to Default Routing Exclusion. =20 > Suggest change to > > DE (DefaultExclusionCapability). >=20 > I'm fine with whatever name majority of people are happy with. I don't know how to sense the majority consensus. Would you agree that Default Exclusion Capability would be more precise? The way that it is named and defined does not hint very well at what it is functionally doing: > MTRoutingExclusionCapability > This is a configurable parameter that will be used to facilitate > the introduction of MT routers in an area and ensure backward > compatibility. vs. DefaultExclusionCapability This configurable parameter, if enabled, enforces that all adjacent neighboring routers have the same capability enabled, such that the default topology can be disabled on a link without causing backward compatability problems. Tom From owner-ospf@PEACH.EASE.LSOFT.COM Mon Apr 18 17:25:20 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14201 for ; Mon, 18 Apr 2005 17:25:19 -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.01019F5A@cherry.ease.lsoft.com>; Mon, 18 Apr 2005 17:25:17 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 67111088 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 18 Apr 2005 17:25:16 -0400 Received: from 130.76.96.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 18 Apr 2005 17:25:16 -0400 Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id QAA12480 for ; Mon, 18 Apr 2005 16:25:15 -0500 (CDT) Received: from XCH-NWBH-02.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j3ILPFm03604 for ; Mon, 18 Apr 2005 16:25:15 -0500 (CDT) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 18 Apr 2005 14:25:04 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: Working Group Last Call on "Multi-Topology (MT) Routing in OSPF" (draft-ietf-ospf-mt-03.txt) Thread-Index: AcVEQXitMj8WRvw4Toiai5y6dZsBrAAEoHqA X-OriginalArrivalTime: 18 Apr 2005 21:25:04.0754 (UTC) FILETIME=[16598520:01C5445D] Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C04060B14@xch-nw-27.nw.nos.boeing.com> Date: Mon, 18 Apr 2005 14:25:04 -0700 Reply-To: Mailing List Sender: Mailing List From: "Henderson, Thomas R" Subject: Re: 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: quoted-printable Tony, replies inline below.=20 > -----Original Message----- > From: Tony Przygienda [mailto:prz@XEBEO.COM]=20 > Sent: Monday, April 18, 2005 1:06 PM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Re: Working Group Last Call on "Multi-Topology (MT)=20 > Routing in OSPF" (draft-ietf-ospf-mt-03.txt) >=20 > > > >"The above specification of MT routing does not allow for forwarding=20 > >paths to be constructed with a mix of MT links and default links, in=20 > >such cases for which a fully MT path does not exist. For=20 > the purpose=20 > >of transition, it is possible to implement an option that=20 > relaxes the=20 > >constraint that all links in an MT path only use MT links. Such an=20 > >option, if used, MUST be applied consistently for a given MT in a=20 > >routing domain (so that consistent forwarding decisions are=20 > made), and=20 > >SHOULD be used with caution by operators because of its potential to=20 > >enable routing loops if configured incorrectly." > > =20 > > > There is a _lot_ of looping potential here from experience. I=20 > am not clear first which scenario you are pursuing. Either >=20 > 1) all routers are MT aware in the deployment, then why don't=20 > you just add the necessary links to the > desired MT topology and you don't need any such hacks. > 2) If you desire to have some routers being non-MT capable,=20 > unless you give > an exact algebra (or worded more simply, rules) that the=20 > operators must follow to avoid the > loops you allure to, how is he supposed to know how to=20 > deploy your hack ? I had in mind #2-- a specific scenario customer for which i) it is operationally difficult to upgrade all routers to MT in same timeframe ii) one or two routers at key points (e.g. network border) are blocking the effective use of MT iii) by inspection of the topology, loops are avoided I agree that the above is a hack and is dangerous in general. Because of that, I will concede that it may be best to leave out of the spec, and treat it as a hack. > > > >Section 3.8 (Forwarding in MT): > >The specification is ambiguous as to how to treat packets=20 > that a) map=20 > >to a defined MT in the area, but b) do not have a path to=20 > the desired=20 > >prefix in the MT topology, yet do have a default path there. In the > >1583 TOS routing, such packets would fall back to the=20 > default topology. > > =20 > > > >I would recommend that such behavior be preserved here,=20 > because it is=20 > >more robust, especially in light of the new capability to=20 > exclude links=20 > >from the default topology if so desired. In fact, it should be=20 > >possible to define the behavior as an option; i.e., one=20 > could configure=20 > >a particular MT-ID to either fallback to default or not. > > =20 > > > MT is _not_ TOS routing (any claim as to that is made purely=20 > to generate confusion IMO). > MT is a solution to generate multiple, _independent_=20 > topologies in the same routing protocol and not a=20 > 'special-capability link' vs. 'general-link'=20 > solution. > Simply forwarding along the default path if a link lacks a MT=20 > metric will lead to routing loops very easily. Example: >=20 > +------ #0/1 ----------------------->C > | ^ > v | > A <-- #1/10 ---> B <---#0/10---------+ > ^ ^ =20 > | | > +-----#0/1-------+ =20 >=20 >=20 > (where #1/X denotes link in topology 1 with metric X, assume=20 > all links bidirectional with same metric, A, B and C all=20 > understand MT). If A forwards to B in topology #1 but B=20 > forwards along the shortest 'default'=20 > path you'll have a > persistent loop.=20 I am not saying (here) to mix and match default and MT links-- clearly, that can lead to loops. Instead, in your example, if A forwards to B in topology #1, it can only do so if the remainder of the path from B to the destination exists in topology #1-- the packet does not (must not) jump out of this topology downstream. If A doesn't have the end-to-end MT path, A will choose the default topology, and B will likewise do so... until (if the case arises) the MT topology does exist to the last hop, in which case the packet can be sucked into the MT topology. To be clear, the two use cases that I have in mind are that i) every router does not necessarily need to enumerate MT-ID for every link in the topology, or ii) not every router is MT capable. > Now start to imagine what will happen if you=20 > start to deal with subset of routers that do not understand=20 > MT on the way. Consider packets that have been traversing a set of non-MT routers, and then suddenly hit an intermediate patch of MT routers (not contiguously connecting to the last hop) for which the packet matches an MT. What should be done with such packets? They cannot be routed to the destination on an MT topology exclusively. Should they be dropped? Maybe, but I would argue that an operator may instead want them to fall back to the default topology in this case. That is, while MTR is not TOS routing, 1583 TOS forwarding behavior should not be precluded (or mandated either-- it should be configurable option). >=20 > I would strongly suggest to leave anything out as to general=20 > fallback-default-topology forwarding from the spec (you're=20 > free of course attempting any little private hack you can get=20 > people to pick up) unless the implications and algorithms are=20 > very tightly written down (as footnote: there exists an=20 > algebra [and algorithm] that deals with this problem=20 > precisely [i.e. default topology being a subset of the MT=20 > topology] but it delivers non-obvious results, especially the=20 > Bellman-suboptimality doesn't hold [i.e. the resulting set of=20 > shortest-paths is not a tree] which is enough to make most=20 > people heads spin and decide they don't care about this=20 > problem all THAT much) >=20 This I would argue is not a hack, but affects how gradual deployment can behave. Returning to a point that Peter made: > - one can define various forwarding behaviors with different=20 > results. As=20 > you said implementation can provide a configurable forwarding=20 > behavior. > - what we specified in the draft was how OSPF should compute=20 > paths and=20 > populate topology specific RIB. I'm not sure the specification of how=20 > the forwarding entries in various RIBs/FIBs are used during the=20 > forwarding belongs to this draft. If you want to take the stance that forwarding is out of scope of the draft (that it only deals with how to build MT RIB-- not how to convert that RIB into a FIB), then I would suggest that the wording in 3.8 be tweaked, because it is making statements about how forwarding works that preclude the forwarding behavior described above. =20 New suggestion: "This document describes how multiple topologies can be built in OSPF's routing information base. It is outside of the scope of this document to describe how these routes are mapped to forwarding rules. It is also outside of the scope of this document to consider different methods of associating an incoming packet to a corresponding topology. User configuration MUST be consistently applied in a network to avoid incorrect forwarding behavior." Tom From owner-ospf@PEACH.EASE.LSOFT.COM Tue Apr 19 03:54: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 DAA15312 for ; Tue, 19 Apr 2005 03:54: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.0101AD64@cherry.ease.lsoft.com>; Tue, 19 Apr 2005 3:54:56 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 67149124 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 19 Apr 2005 03:54:14 -0400 Received: from 144.254.15.118 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 19 Apr 2005 03:54:13 -0400 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 j3J7sCD19347 for ; Tue, 19 Apr 2005 09:54:12 +0200 (CEST) Received: from cisco.com (ppsenak--isdn-home4.cisco.com [10.49.2.221]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j3J7sCK08181 for ; Tue, 19 Apr 2005 09:54:12 +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: <6938661A6EDA8A4EA8D1419BCE46F24C0664919E@xch-nw-27.nw.nos.boeing.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <4264B923.6080307@cisco.com> Date: Tue, 19 Apr 2005 09:54:11 +0200 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) To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Thomas, please see inline: Henderson, Thomas R wrote: >>Section 4.4. >> >>- sending of OSPF control packets is unchanged from RFC2328 >>- link being enabled/disabled in the default topology only >>affects what is being advertised by OSPF. It does not affect >>installation of connected routes to the RIB that corresponds >>to the default topology > > > I don't think that the existing text is saying the above bullets, or at > least, it is possible to interpet it differently (as I apparently did). > > Is the following what you want to say? > "Sending of OSPF control packets is unchanged from RFC2328, except in > the case of sending OSPF packets across virtual links, in which case the > intra-area path of the virtual link MUST only be composed of links on > the default topology, and OSPF control packets being forwarded MUST be > forwarded using the default topology." > > If so, I would suggest changing 3.3 to the above, and removing 4.4. > even the case of VL does not really change from the RFC2328. What about this wording: "Sending of OSPF control packets is unchanged from RFC2328. For OSPF control packets sent to the remote end of the VL, intra-area path to the remote end MUST only be composed of links in the default topology and OSPF control packets being forwarded MUST be forwarded using the default topology." 4.4 was added to make it clear that disabling the default topology on the interface only affects what OSPF advertises and has no impact on installation of connected route in default RIB. > >> MTRoutingExclusionCapability >> This is a configurable parameter that will be used to facilitate >> the introduction of MT routers in an area and ensure backward >> compatibility. > > > vs. > DefaultExclusionCapability > This configurable parameter, if enabled, enforces that all > adjacent neighboring routers have the same capability enabled, such that > the default topology can be disabled on a link without causing backward > compatability problems. ok, DefaultExclusionCapability be it. Peter From owner-ospf@PEACH.EASE.LSOFT.COM Tue Apr 19 04:03: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 EAA15842 for ; Tue, 19 Apr 2005 04:03: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 <22.0101AD97@cherry.ease.lsoft.com>; Tue, 19 Apr 2005 4:03:32 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 67149523 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 19 Apr 2005 04:02:41 -0400 Received: from 144.254.15.118 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 19 Apr 2005 04:02:41 -0400 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 j3J82eb20151 for ; Tue, 19 Apr 2005 10:02:40 +0200 (CEST) Received: from cisco.com (ppsenak--isdn-home4.cisco.com [10.49.2.221]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j3J82dK15717 for ; Tue, 19 Apr 2005 10:02:39 +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: <6938661A6EDA8A4EA8D1419BCE46F24C04060B14@xch-nw-27.nw.nos.boeing.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <4264BB1F.2030601@cisco.com> Date: Tue, 19 Apr 2005 10:02:39 +0200 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) To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Thomas, Henderson, Thomas R wrote: > > > Returning to a point that Peter made: > > >>- one can define various forwarding behaviors with different >>results. As >>you said implementation can provide a configurable forwarding >>behavior. >>- what we specified in the draft was how OSPF should compute >>paths and >>populate topology specific RIB. I'm not sure the specification of how >>the forwarding entries in various RIBs/FIBs are used during the >>forwarding belongs to this draft. > > > If you want to take the stance that forwarding is out of scope of the > draft (that it only deals with how to build MT RIB-- not how to convert > that RIB into a FIB), then I would suggest that the wording in 3.8 be > tweaked, because it is making statements about how forwarding works that > preclude the forwarding behavior described above. > > New suggestion: > > "This document describes how multiple topologies can be built in OSPF's > routing information base. It is outside of the scope of this document > to describe how these routes are mapped to forwarding rules. It is also > outside of the scope of this document to consider different methods of > associating an incoming packet to a corresponding topology. User > configuration MUST be consistently applied in a network to avoid > incorrect forwarding behavior." I'll reword 3.8 Peter From owner-ospf@PEACH.EASE.LSOFT.COM Tue Apr 19 09:28:14 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09363 for ; Tue, 19 Apr 2005 09:28:14 -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 <0.0101B343@cherry.ease.lsoft.com>; Tue, 19 Apr 2005 9:28:12 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 67194793 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 19 Apr 2005 09:28:02 -0400 Received: from 207.17.137.64 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 19 Apr 2005 09:28:02 -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 j3JDS1Bm068636 for ; Tue, 19 Apr 2005 06:28:01 -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 j3JDRue25264 for ; Tue, 19 Apr 2005 06:27:56 -0700 (PDT) (envelope-from yakov@juniper.net) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <70426.1113917275.1@juniper.net> Message-ID: <200504191327.j3JDRue25264@merlot.juniper.net> Date: Tue, 19 Apr 2005 06:27:56 -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) To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Your message of "Tue, 19 Apr 2005 10:02:39 +0200." <4264BB1F.2030601@cisco.com> Precedence: list Peter, > > If you want to take the stance that forwarding is out of scope of the > > draft (that it only deals with how to build MT RIB-- not how to convert > > that RIB into a FIB), then I would suggest that the wording in 3.8 be > > tweaked, because it is making statements about how forwarding works that > > preclude the forwarding behavior described above. > > > > New suggestion: > > > > "This document describes how multiple topologies can be built in OSPF's > > routing information base. It is outside of the scope of this document > to describe how these routes are mapped to forwarding rules. It is also > > outside of the scope of this document to consider different methods of > > associating an incoming packet to a corresponding topology. User > > configuration MUST be consistently applied in a network to avoid > > incorrect forwarding behavior." > > I'll reword 3.8 Actually what needs to be consistenly applied in a network are the rules for how routes are mapped into forwarding rules and methods of associating an incoming packet to a corresponding topology. Yakov. From owner-ospf@PEACH.EASE.LSOFT.COM Tue Apr 19 10:55:45 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17621 for ; Tue, 19 Apr 2005 10:55:40 -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.0101B4FF@cherry.ease.lsoft.com>; Tue, 19 Apr 2005 10:55:40 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 67205985 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 19 Apr 2005 10:55:39 -0400 Received: from 216.37.114.8 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 19 Apr 2005 10:55:32 -0400 Received: (qmail 7203 invoked from network); 19 Apr 2005 14:55:21 -0000 Received: from unknown (HELO ?192.168.1.28?) (172.16.104.134) by lxmail.nj.us.utstar.com with SMTP; 19 Apr 2005 14:55:21 -0000 User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.6) Gecko/20050328 Fedora/1.7.6-1.2.5 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <6938661A6EDA8A4EA8D1419BCE46F24C04060B14@xch-nw-27.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <426537F8.8060306@xebeo.com> Date: Tue, 19 Apr 2005 16:55:20 +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) To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C04060B14@xch-nw-27.nw.nos.boeing.com> Precedence: list Content-Transfer-Encoding: 7bit Henderson, Thomas R wrote: >Tony, replies inline below. > > > >>> >>> >>There is a _lot_ of looping potential here from experience. I >>am not clear first which scenario you are pursuing. Either >> >>1) all routers are MT aware in the deployment, then why don't >>you just add the necessary links to the >> desired MT topology and you don't need any such hacks. >>2) If you desire to have some routers being non-MT capable, >>unless you give >> an exact algebra (or worded more simply, rules) that the >>operators must follow to avoid the >> loops you allure to, how is he supposed to know how to >>deploy your hack ? >> >> > >I had in mind #2-- a specific scenario customer for which >i) it is operationally difficult to upgrade all routers to MT in same >timeframe >ii) one or two routers at key points (e.g. network border) are blocking >the effective use of MT > > ok, I would gladly yield to your pressure to do so ;-) >iii) by inspection of the topology, loops are avoided > > huh, that concept I cannot become friend with. Kind of takes the reason-d'etre of dynamic routing away. >I agree that the above is a hack and is dangerous in general. Because >of that, I will concede that it may be best to leave out of the spec, >and treat it as a hack. > > agreed. > >>.... >> >>(where #1/X denotes link in topology 1 with metric X, assume >>all links bidirectional with same metric, A, B and C all >>understand MT). If A forwards to B in topology #1 but B >>forwards along the shortest 'default' >>path you'll have a >>persistent loop. >> >> > >I am not saying (here) to mix and match default and MT links-- clearly, >that can lead to loops. Instead, in your example, if A forwards to B in >topology #1, it can only do so if the remainder of the path from B to >the destination exists in topology #1-- the packet does not (must not) >jump out of this topology downstream. If A doesn't have the end-to-end >MT path, A will choose the default topology, and B will likewise do >so... until (if the case arises) the MT topology does exist to the last >hop, in which case the packet can be sucked into the MT topology. > > ok, yes, that is actually one possible solution for the algebra of this kind of nested topologies (this solution proven to be loop-free) but then you MUST specify the according behavior in the spec (i.e., every MT router, if a topology X !=0 path end-2-end does not exist, MUST forward along the default topology, EVEN if a topology X next-hop exists! That's what I ment by such an SPF not being a tree anymore since what you have in terms of forwarding paths to all destinations on the network is all of a sudden only a DAG. I assume as well that you want to drop the packet if there is not path in #X and in #0. That's also OK. Footnote if you're interested: it is possible to 'jump up' a topology, i.e. you can start routing along default path and then if a router knows a feasible path in #X to destination, it can forward the packet along that path. That however just complicates the behavior for minimal gain. > > >>Now start to imagine what will happen if you >>start to deal with subset of routers that do not understand >>MT on the way. >> >> > >Consider packets that have been traversing a set of non-MT routers, and >then suddenly hit an intermediate patch of MT routers (not contiguously >connecting to the last hop) for which the packet matches an MT. What >should be done with such packets? They cannot be routed to the >destination on an MT topology exclusively. Should they be dropped? >Maybe, but I would argue that an operator may instead want them to fall >back to the default topology in this case. > > yes, as above, as long as ALL the routers (from the first on) forward along default topology you will be ok. >That is, while MTR is not TOS routing, 1583 TOS forwarding behavior >should not be precluded (or mandated either-- it should be configurable >option). > > It is just _confusing_ insisting on calling this thing TOS forwarding. TOS is just one topology with all the same prefixes and an undeployed forwarding 'hack'. Here, when you implement what you are talking about correctly, you will realize that you are running into a completely different beast, you must run kind of a nested SPF (and for the spec, you better write the algorithm cleanly down, it's not trivial) for _each_ topology #0 you want to be able to 'downgrade' to default-topology forwarding since otherwise you will be very confused as to which prefixes belong to which topology (and don't forget, they can overlap if you 'flatten' the topologies). As well, your hack will force you for each incoming packet on each link to be able to classify it as belonging to any topology #0, rather than just the ones you configured on the link, maybe an expensive operation. > > >>I would strongly suggest to leave anything out as to general >>fallback-default-topology forwarding from the spec (you're >>free of course attempting any little private hack you can get >>people to pick up) unless the implications and algorithms are >>very tightly written down (as footnote: there exists an >>algebra [and algorithm] that deals with this problem >>precisely [i.e. default topology being a subset of the MT >>topology] but it delivers non-obvious results, especially the >>Bellman-suboptimality doesn't hold [i.e. the resulting set of >>shortest-paths is not a tree] which is enough to make most >>people heads spin and decide they don't care about this >>problem all THAT much) >> >> >> > >This I would argue is not a hack, but affects how gradual deployment can >behave. > > > > >>- one can define various forwarding behaviors with different >>results. As >>you said implementation can provide a configurable forwarding >>behavior. >>- what we specified in the draft was how OSPF should compute >>paths and >>populate topology specific RIB. I'm not sure the specification of how >>the forwarding entries in various RIBs/FIBs are used during the >>forwarding belongs to this draft. >> >> > >If you want to take the stance that forwarding is out of scope of the >draft (that it only deals with how to build MT RIB-- not how to convert >that RIB into a FIB), then I would suggest that the wording in 3.8 be >tweaked, because it is making statements about how forwarding works that >preclude the forwarding behavior described above. > > Read section 12. of the MT ISIS draft, I would suggest. Forwarding behavior (and FIB segregation) can be 'classified' into a framework but it cannot be 'prescribed' IMO and that's why I wouldn't put your 'addition' into the draft either. In pretty general terms, what Yakov wrote is correct, albeit you can generalize it even further to say that a chain (in mathematical sense) of forwarding classifications and forwarding behaviors in the network must exist that is loop-free [that's where the 'algebra' I mention all the time comes in, the algebra actually seems to suggest that the whole thing is a 'ring' and the forwarding behaviors 'must' be a chain, here however my math background is too weak, I used to work places where I had a 'crutch' of an ingenious russian mathematician who was far more smart than I was but I tended to understand the practical problems to take his tools to better ;-) I know a couple of 'fancy' ways people do forwarding on MT these days, e.g. one deployment feeds couple of topologies into a single one. I think your 'addition' will become more and more complicated in all those scenarios (albeit, as I said, an algebra exists to prove/disprove the correctness and completeness of an according forwarding behavior [i.e. behavior that uses the 'default' topology as 'backup']) Final remark: One of the things with the MT draft was that ISP people (at least some I talked to) are fairly paranoid when selling any kind of 'partitioned' network for packet not to end up in the 'wrong' topology for security reasons. Your 'addition' would cause packets to show up in funny places that overlap with other people topologies . Maybe an issue, maybe not since OSPF/ISIS are IGPs and therefore pretty much all one control AD for the ISP. --- tony From owner-ospf@PEACH.EASE.LSOFT.COM Tue Apr 19 13:56:32 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01979 for ; Tue, 19 Apr 2005 13:56: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.0101B82A@cherry.ease.lsoft.com>; Tue, 19 Apr 2005 13:56:30 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 67222691 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 19 Apr 2005 13:56:28 -0400 Received: from 171.71.176.71 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 19 Apr 2005 13:56:14 -0400 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-2.cisco.com with ESMTP; 19 Apr 2005 10:56:14 -0700 Received: from [128.107.134.5] (naiming-linux.cisco.com [128.107.134.5]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j3JHuCpR012353 for ; Tue, 19 Apr 2005 10:56:12 -0700 (PDT) User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <6938661A6EDA8A4EA8D1419BCE46F24C04060B14@xch-nw-27.nw.nos.boeing.com> <426537F8.8060306@xebeo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <4265463C.7010603@cisco.com> Date: Tue, 19 Apr 2005 10:56:12 -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) To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <426537F8.8060306@xebeo.com> Precedence: list Content-Transfer-Encoding: 7bit I agree that the default topology "jumping" should not be in this spec. Routers want to do that need to consider, why just jumping to the "default topology" not some other topologies; how the reply packets come back to the source if they do that; and security considerations. I think a better way to achieve the goal is to do "redistribution". We can think of them as a provider running both ISIS and OSPF in two different topologies, and some of the routes need to be announced into other side. This is a clean design and can be easily controlled. It's an implementation and configuration issue. Just be careful to tag those "redistributed" routes so they will not be "redistributed" back into the original topology on another router thus causing packets looping. thanks. - Naiming Tony Przygienda said the following on 04/19/2005 09:55 AM: > Henderson, Thomas R wrote: > >> Tony, replies inline below. >> >> >>>> >>> >>> There is a _lot_ of looping potential here from experience. I am not >>> clear first which scenario you are pursuing. Either >>> >>> 1) all routers are MT aware in the deployment, then why don't you >>> just add the necessary links to the >>> desired MT topology and you don't need any such hacks. >>> 2) If you desire to have some routers being non-MT capable, unless >>> you give >>> an exact algebra (or worded more simply, rules) that the operators >>> must follow to avoid the >>> loops you allure to, how is he supposed to know how to deploy your >>> hack ? >>> >> >> >> I had in mind #2-- a specific scenario customer for which >> i) it is operationally difficult to upgrade all routers to MT in same >> timeframe >> ii) one or two routers at key points (e.g. network border) are blocking >> the effective use of MT >> >> > ok, I would gladly yield to your pressure to do so ;-) > >> iii) by inspection of the topology, loops are avoided >> >> > huh, that concept I cannot become friend with. Kind of takes the > reason-d'etre > of dynamic routing away. > >> I agree that the above is a hack and is dangerous in general. Because >> of that, I will concede that it may be best to leave out of the spec, >> and treat it as a hack. >> >> > agreed. > >> >>> .... >>> >>> (where #1/X denotes link in topology 1 with metric X, assume all >>> links bidirectional with same metric, A, B and C all understand MT). >>> If A forwards to B in topology #1 but B forwards along the shortest >>> 'default' path you'll have a >>> persistent loop. >> >> >> I am not saying (here) to mix and match default and MT links-- clearly, >> that can lead to loops. Instead, in your example, if A forwards to B in >> topology #1, it can only do so if the remainder of the path from B to >> the destination exists in topology #1-- the packet does not (must not) >> jump out of this topology downstream. If A doesn't have the end-to-end >> MT path, A will choose the default topology, and B will likewise do >> so... until (if the case arises) the MT topology does exist to the last >> hop, in which case the packet can be sucked into the MT topology. >> >> > ok, yes, that is actually one possible solution for the algebra of this > kind of nested > topologies (this solution proven to be loop-free) but then you MUST > specify the according behavior > in the spec (i.e., every MT router, if a topology X !=0 path end-2-end > does not exist, > MUST forward along the default topology, EVEN if a topology X next-hop > exists! > That's what I ment by such an SPF not being a tree anymore since what > you have in > terms of forwarding paths to all destinations on the network is all of a > sudden only a DAG. > I assume as well that you want > to drop the packet if there is not path in #X and in #0. That's also OK. > > Footnote if you're interested: it is possible to 'jump up' a topology, i.e. > you can start routing along default path and then if a router knows a > feasible > path in #X to destination, it can forward the packet along that path. > That however > just complicates the behavior for minimal gain. > >> >> >>> Now start to imagine what will happen if you start to deal with >>> subset of routers that do not understand MT on the way. >>> >> >> >> Consider packets that have been traversing a set of non-MT routers, and >> then suddenly hit an intermediate patch of MT routers (not contiguously >> connecting to the last hop) for which the packet matches an MT. What >> should be done with such packets? They cannot be routed to the >> destination on an MT topology exclusively. Should they be dropped? >> Maybe, but I would argue that an operator may instead want them to fall >> back to the default topology in this case. >> >> > yes, as above, as long as ALL the routers (from the first on) forward along > default topology you will be ok. > >> That is, while MTR is not TOS routing, 1583 TOS forwarding behavior >> should not be precluded (or mandated either-- it should be configurable >> option). >> >> > It is just _confusing_ insisting on calling this thing TOS forwarding. > TOS is just > one topology with all the same prefixes and an undeployed forwarding > 'hack'. Here, > when you implement what you are talking about correctly, you will > realize that > you are running into a completely different beast, you must run kind of > a nested SPF > (and for the spec, you better write the algorithm cleanly down, it's not > trivial) > for _each_ topology #0 you want to be able to 'downgrade' to > default-topology > forwarding since otherwise you will be very confused as to which prefixes > belong to which topology (and don't forget, they can overlap if you > 'flatten' the > topologies). As well, your hack will force you for each incoming packet > on each link to > be able to classify it as belonging to any topology #0, rather than just > the > ones you configured on the link, maybe an expensive operation. > >> >> >>> I would strongly suggest to leave anything out as to general >>> fallback-default-topology forwarding from the spec (you're free of >>> course attempting any little private hack you can get people to pick >>> up) unless the implications and algorithms are very tightly written >>> down (as footnote: there exists an algebra [and algorithm] that deals >>> with this problem precisely [i.e. default topology being a subset of >>> the MT topology] but it delivers non-obvious results, especially the >>> Bellman-suboptimality doesn't hold [i.e. the resulting set of >>> shortest-paths is not a tree] which is enough to make most people >>> heads spin and decide they don't care about this problem all THAT much) >>> >>> >> >> >> This I would argue is not a hack, but affects how gradual deployment can >> behave. >> >> >> >> >>> - one can define various forwarding behaviors with different results. >>> As you said implementation can provide a configurable forwarding >>> behavior. >>> - what we specified in the draft was how OSPF should compute paths >>> and populate topology specific RIB. I'm not sure the specification of >>> how the forwarding entries in various RIBs/FIBs are used during the >>> forwarding belongs to this draft. >>> >> >> >> If you want to take the stance that forwarding is out of scope of the >> draft (that it only deals with how to build MT RIB-- not how to convert >> that RIB into a FIB), then I would suggest that the wording in 3.8 be >> tweaked, because it is making statements about how forwarding works that >> preclude the forwarding behavior described above. >> > Read section 12. of the MT ISIS draft, I would suggest. Forwarding behavior > (and FIB segregation) can be 'classified' into a framework but it cannot be > 'prescribed' IMO and that's why I wouldn't put your 'addition' into the > draft either. > In pretty general terms, what Yakov wrote is correct, albeit you can > generalize it even further to say that a chain (in mathematical sense) > of forwarding > classifications and forwarding behaviors in the network must exist that > is loop-free > [that's where the 'algebra' I mention all the time comes in, the algebra > actually > seems to suggest that the whole thing is a 'ring' and the forwarding > behaviors > 'must' be a chain, here however my math background is too weak, I used > to work > places where I had a 'crutch' of an ingenious russian mathematician who > was far more smart > than I was but I tended to understand the practical problems to take his > tools to better ;-) > I know a couple of 'fancy' > ways people do forwarding on MT these days, e.g. one deployment feeds > couple of > topologies into a single one. I think your 'addition' will become more > and more > complicated in all those scenarios (albeit, as I said, an algebra exists > to prove/disprove > the correctness and completeness of an according forwarding behavior > [i.e. behavior > that uses the 'default' topology as 'backup']) > > Final remark: One of the things with the MT draft was that ISP people > (at least some I talked to) > are fairly paranoid when selling any kind of 'partitioned' network for > packet not to end up in > the 'wrong' topology for security reasons. Your 'addition' would cause > packets to show up in > funny places that overlap with other people topologies . Maybe an issue, > maybe not since > OSPF/ISIS are IGPs and therefore pretty much all one control AD for the > ISP. > > --- tony From owner-ospf@PEACH.EASE.LSOFT.COM Tue Apr 19 15:49: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 PAA14540 for ; Tue, 19 Apr 2005 15:49:19 -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 <0.0101BEF5@cherry.ease.lsoft.com>; Tue, 19 Apr 2005 15:49:16 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 67235002 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 19 Apr 2005 15:49:05 -0400 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 19 Apr 2005 15:39:04 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12980; Tue, 19 Apr 2005 15:39:02 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200504191939.PAA12980@ietf.org> Date: Tue, 19 Apr 2005 15:39:02 -0400 Reply-To: Mailing List Sender: Mailing List From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ospf-mt-ospfv3-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 : Multi-topology routing in OSPFv3 (MT-OSPFv3) Author(s) : S. Mirtorabi, A. Roy Filename : draft-ietf-ospf-mt-ospfv3-00.txt Pages : 25 Date : 2005-4-19 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-ietf-ospf-mt-ospfv3-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-mt-ospfv3-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-mt-ospfv3-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-19154326.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ospf-mt-ospfv3-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ospf-mt-ospfv3-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-4-19154326.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@PEACH.EASE.LSOFT.COM Wed Apr 20 10:40:32 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15294 for ; Wed, 20 Apr 2005 10:40: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 <2.0101D67F@cherry.ease.lsoft.com>; Wed, 20 Apr 2005 10:40:30 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 67358012 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 20 Apr 2005 10:40:29 -0400 Received: from 64.102.122.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 20 Apr 2005 10:40:29 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 20 Apr 2005 10:40:29 -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 j3KEeCe7017169 for ; Wed, 20 Apr 2005 10:40:26 -0400 (EDT) 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); Wed, 20 Apr 2005 10:40:25 -0400 Received: from [10.82.225.177] ([10.82.225.177]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 20 Apr 2005 10:40:25 -0400 User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <4251C399.8030906@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Apr 2005 14:40:25.0225 (UTC) FILETIME=[E372E790:01C545B6] Message-ID: <426669D8.4090907@cisco.com> Date: Wed, 20 Apr 2005 10:40:24 -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: <4251C399.8030906@cisco.com> Precedence: list Content-Transfer-Encoding: 7bit The Working Group last call for the subject document has completed. The next version will address the comments received during the last call. The next version will include a section precisely describing the protocol differences between RFC 1583 TOS routing and multi-topology routing. Personally, I don't think we need a section on requirements or deployment scenarios. I'm sure that everyone can recall the famous, yet unnamed, service provider that wished to offer gold, silver, and bronze service level agreements (SLAs) to their customers - now they simply want to to use incongruent topologies to guarentee these SLAs. Of course, this is just one of the many possible applications for multi-topology routing. Thanks, Acee Acee Lindem wrote: > 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 Fri Apr 22 07:03:20 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05239 for ; Fri, 22 Apr 2005 07:03:20 -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.01020ADE@cherry.ease.lsoft.com>; Fri, 22 Apr 2005 7:03:18 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 67616048 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 22 Apr 2005 07:03:17 -0400 Received: from 64.233.170.194 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 22 Apr 2005 07:03:17 -0400 Received: by rproxy.gmail.com with SMTP id f1so889354rne for ; Fri, 22 Apr 2005 04:03:16 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=fG2IEgeR8bnwS2IBa10yk574iNnqaLx8mqh/Fnt2F7YbVuiLJLaBvHTEY5EX9DRidsPSmtFRocrqrxsKPuOvvuwGq8KKLp1tUZUk/RVoUOhRCNo9aF/Gn5FuKfF3Fl809360AREsg/mTgNovc8ErD9JkoVvA2rn2F7gEy4JovXQ= Received: by 10.38.24.45 with SMTP id 45mr3257977rnx; Fri, 22 Apr 2005 04:03:16 -0700 (PDT) Received: by 10.38.76.75 with HTTP; Fri, 22 Apr 2005 04:03:16 -0700 (PDT) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-ID: Date: Fri, 22 Apr 2005 16:33:16 +0530 Reply-To: Mailing List Sender: Mailing List From: Deepak Dandekar Subject: status of RFC 2154 To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Hello, I tried searching for this RFC on the OSPF charter, but didn't find any information. Is there any vendor who has implemented this RFC? Is there any need to implement this RFC?? Appreciate your help. thanks, deepak. From owner-ospf@PEACH.EASE.LSOFT.COM Fri Apr 22 11:15: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 LAA26563 for ; Fri, 22 Apr 2005 11:15:01 -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.010216D9@cherry.ease.lsoft.com>; Fri, 22 Apr 2005 11:15:01 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 67639626 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 22 Apr 2005 11:15:00 -0400 Received: from 64.102.122.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 22 Apr 2005 11:15:00 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 22 Apr 2005 11:26:25 -0400 X-IronPort-AV: i="3.92,124,1112587200"; d="scan'208"; a="45730347:sNHT25859288" 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 j3MFETeL008031 for ; Fri, 22 Apr 2005 11:14:57 -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); Fri, 22 Apr 2005 11:14:46 -0400 Received: from [10.82.241.23] ([10.82.241.23]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 22 Apr 2005 11:14:45 -0400 User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Apr 2005 15:14:45.0532 (UTC) FILETIME=[04504DC0:01C5474E] Message-ID: <426914E6.8060902@cisco.com> Date: Fri, 22 Apr 2005 11:14:46 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: status of RFC 2154 To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit Hi Deepak, Deepak Dandekar wrote: >Hello, >I tried searching for this RFC on the OSPF charter, but didn't find >any information. > > It is an experimental RFC that went through a different process than standards track WG documents. Another example would be RFC 2676. >Is there any vendor who has implemented this RFC? > I don't know of any commercial implementations. However, I haven't looked too hard either. >Is there any need to >implement this RFC?? > > I wouldn't think so. However, I'm somewhat biased since I don't really think this is a good idea. I certainly don't want to quell any innovation. Hope this helps, Acee >Appreciate your help. > >thanks, >deepak. > > > From owner-ospf@PEACH.EASE.LSOFT.COM Fri Apr 22 16:04:36 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21279 for ; Fri, 22 Apr 2005 16:04:36 -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.01021B8F@cherry.ease.lsoft.com>; Fri, 22 Apr 2005 16:04:34 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 67673458 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 22 Apr 2005 16:04:33 -0400 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 22 Apr 2005 15:54:33 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18317; Fri, 22 Apr 2005 15:54:31 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200504221954.PAA18317@ietf.org> Date: Fri, 22 Apr 2005 15:54:30 -0400 Reply-To: Mailing List Sender: Mailing List From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ospf-mt-04.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 : Multi-Topology (MT) Routing in OSPF Author(s) : P. Psenak, et al. Filename : draft-ietf-ospf-mt-04.txt Pages : 23 Date : 2005-4-22 This draft describes an extension to OSPF in order to define independent IP topologies called Multi-Topologies (MTs). The MT extension can be used for computing different paths for unicast traffic, multicast traffic, different classes of service based on flexible criteria, or an in-band network management topology. [M-ISIS] describes a similar mechanism for ISIS. An optional extension to exclude selected links from the default topology is also described. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-mt-04.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-mt-04.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-mt-04.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-22162316.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ospf-mt-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ospf-mt-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-4-22162316.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@PEACH.EASE.LSOFT.COM Fri Apr 22 16:57:01 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01923 for ; Fri, 22 Apr 2005 16:57:01 -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.01021BD9@cherry.ease.lsoft.com>; Fri, 22 Apr 2005 16:57:01 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 67677558 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 22 Apr 2005 16:56:59 -0400 Received: from 171.68.10.87 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 22 Apr 2005 16:55:34 -0400 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 22 Apr 2005 13:55:34 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j3MKsmpt029627 for ; Fri, 22 Apr 2005 13:55:31 -0700 (PDT) Received: from xfe-rtp-211.amer.cisco.com ([64.102.31.113]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 22 Apr 2005 16:55:20 -0400 Received: from [10.82.241.23] ([10.82.241.23]) by xfe-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 22 Apr 2005 16:55:20 -0400 User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <200504221954.PAA18317@ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Apr 2005 20:55:20.0429 (UTC) FILETIME=[987621D0:01C5477D] Message-ID: <426964B7.7020103@cisco.com> Date: Fri, 22 Apr 2005 16:55:19 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: I-D ACTION:draft-ietf-ospf-mt-04.txt To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <200504221954.PAA18317@ietf.org> Precedence: list Content-Transfer-Encoding: 7bit This version has been updated to address the WG last call comments. IMHO, it is now ready to go to the IESG. Thanks, Acee Internet-Drafts@IETF.ORG wrote: >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF. > > Title : Multi-Topology (MT) Routing in OSPF > Author(s) : P. Psenak, et al. > Filename : draft-ietf-ospf-mt-04.txt > Pages : 23 > Date : 2005-4-22 > >This draft describes an extension to OSPF in order to define > independent IP topologies called Multi-Topologies (MTs). The MT > extension can be used for computing different paths for unicast > traffic, multicast traffic, different classes of service based on > flexible criteria, or an in-band network management topology. > [M-ISIS] describes a similar mechanism for ISIS. > > An optional extension to exclude selected links from the default > topology is also described. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-ospf-mt-04.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-mt-04.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-mt-04.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: j3MK5QLQ008670 > >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 > > From owner-ospf@PEACH.EASE.LSOFT.COM Mon Apr 25 17:02: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 RAA29528 for ; Mon, 25 Apr 2005 17:01: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 <4.01025112@cherry.ease.lsoft.com>; Mon, 25 Apr 2005 17:01:44 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 68068089 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 25 Apr 2005 17:01:43 -0400 Received: from 64.102.122.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 25 Apr 2005 17:01:43 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 25 Apr 2005 17:13:42 -0400 X-IronPort-AV: i="3.92,128,1112587200"; d="scan'208"; a="46041046:sNHT30120800" 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 j3PL0aeD012633; Mon, 25 Apr 2005 17:01:30 -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, 25 Apr 2005 17:01:13 -0400 Received: from [64.102.198.255] ([64.102.198.255]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 25 Apr 2005 17:01:13 -0400 User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <200504221954.PAA18317@ietf.org> <426964B7.7020103@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Apr 2005 21:01:13.0539 (UTC) FILETIME=[EA2BB130:01C549D9] Message-ID: <426D5A97.6050609@cisco.com> Date: Mon, 25 Apr 2005 17:01:11 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: I-D ACTION:draft-ietf-ospf-mt-04.txt Comments: To: Alex Zinin , Bill Fenner , IESG Secretary To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <426964B7.7020103@cisco.com> Precedence: list Content-Transfer-Encoding: 7bit The subject document has completed OSPF WG last call and is ready for IESG review. Thanks, Acee and Rohit Acee Lindem wrote: > This version has been updated to address the WG last call comments. > IMHO, it is > now ready to go to the IESG. > > Thanks, > Acee > > > Internet-Drafts@IETF.ORG wrote: > >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Open Shortest Path First IGP Working >> Group of the IETF. >> >> Title : Multi-Topology (MT) Routing in OSPF >> Author(s) : P. Psenak, et al. >> Filename : draft-ietf-ospf-mt-04.txt >> Pages : 23 >> Date : 2005-4-22 >> >> This draft describes an extension to OSPF in order to define >> independent IP topologies called Multi-Topologies (MTs). The MT >> extension can be used for computing different paths for unicast >> traffic, multicast traffic, different classes of service based on >> flexible criteria, or an in-band network management topology. >> [M-ISIS] describes a similar mechanism for ISIS. >> >> An optional extension to exclude selected links from the default >> topology is also described. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-ospf-mt-04.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-mt-04.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-mt-04.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: j3MK5QLQ008670 >> >> 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 >> >> >