From MAILER-DAEMON Thu Apr 4 14:38:11 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05954 for ; Thu, 4 Apr 2002 14:38:11 -0500 (EST) Message-Id: <200204041938.OAA05954@ietf.org> Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <7.FEBE479B@PEAR.EASE.LSOFT.COM>; Thu, 4 Apr 2002 14:37:54 -0500 Date: Thu, 4 Apr 2002 14:37:53 -0500 From: "L-Soft list server at DISCUSS.MICROSOFT.COM (1.8d)" Subject: Output of your job "ospf-archive" To: ospf-archive@ietf.org > subscribe ospf Please type your name after the name of the list, as in: "SUBSCRIBE OSPF Joe H. Smith". Alternatively, if you want to subscribe anonymously, send the command: "SUBSCRIBE OSPF Anonymous". Your subscription will then be hidden automatically. Summary of resource utilization ------------------------------- CPU time: 0.000 sec Overhead CPU: 0.000 sec CPU model: ~1125MHz Pentium II 512k (1280M) Job origin: ospf-archive@IETF.ORG From owner-OSPF@DISCUSS.MICROSOFT.COM Wed Apr 10 22:25:20 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08205 for ; Wed, 10 Apr 2002 22:25:20 -0400 (EDT) Message-Id: <200204110225.WAA08205@ietf.org> Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <7.FEBE4A25@PEAR.EASE.LSOFT.COM>; Wed, 10 Apr 2002 22:25:21 -0500 Date: Wed, 10 Apr 2002 22:25:23 -0400 From: "L-Soft list server at DISCUSS.MICROSOFT.COM (1.8d)" Subject: You are now subscribed to the OSPF list To: ospf-archive@ietf.org Reply-To: OSPF-request@DISCUSS.MICROSOFT.COM X-LSV-ListID: OSPF Wed, 10 Apr 2002 22:25:23 Your subscription to the OSPF list (Mailing List) has been accepted. Please save this message for future reference, especially if this is the first time you are subscribing to an electronic mailing list. If you ever need to leave the list, you will find the necessary instructions below. Perhaps more importantly, saving a copy of this message (and of all future subscription notices from other mailing lists) in a special mail folder will give you instant access to the list of mailing lists that you are subscribed to. This may prove very useful the next time you go on vacation and need to leave the lists temporarily so as not to fill up your mailbox while you are away! You should also save the "welcome messages" from the list owners that you will occasionally receive after subscribing to a new list. To send a message to all the people currently subscribed to the list, just send mail to OSPF@DISCUSS.MICROSOFT.COM. This is called "sending mail to the list," because you send mail to a single address and LISTSERV makes copies for all the people who have subscribed. This address (OSPF@DISCUSS.MICROSOFT.COM) is also called the "list address." You must never try to send any command to that address, as it would be distributed to all the people who have subscribed. All commands must be sent to the "LISTSERV address," LISTSERV@DISCUSS.MICROSOFT.COM. It is very important to understand the difference between the two, but fortunately it is not complicated. The LISTSERV address is like a FAX number that connects you to a machine, whereas the list address is like a normal voice line connecting you to a person. If you make a mistake and dial the FAX number when you wanted to talk to someone on the phone, you will quickly realize that you used the wrong number and call again. No harm will have been done. If on the other hand you accidentally make your FAX call someone's voice line, the person receiving the call will be inconvenienced, especially if your FAX then re-dials every 5 minutes. The fact that most people will eventually connect the FAX machine to the voice line to allow the FAX to go through and make the calls stop does not mean that you should continue to send FAXes to the voice number. People would just get mad at you. It works pretty much the same way with mailing lists, with the difference that you are calling hundreds or thousands of people at the same time, and consequently you can expect a lot of people to get upset if you consistently send commands to the list address. You may leave the list at any time by sending a "SIGNOFF OSPF" command to LISTSERV@DISCUSS.MICROSOFT.COM. You can also tell LISTSERV how you want it to confirm the receipt of messages you send to the list. If you do not trust the system, send a "SET OSPF REPRO" command and LISTSERV will send you a copy of your own messages, so that you can see that the message was distributed and did not get damaged on the way. After a while you may find that this is getting annoying, especially if your mail program does not tell you that the message is from you when it informs you that new mail has arrived from OSPF. If you send a "SET OSPF ACK NOREPRO" command, LISTSERV will mail you a short acknowledgement instead, which will look different in your mailbox directory. With most mail programs you will know immediately that this is an acknowledgement you can read later. Finally, you can turn off acknowledgements completely with "SET OSPF NOACK NOREPRO". Following instructions from the list owner, your subscription options have been set to "REPRO NOACK CONCEAL" rather than the usual LISTSERV defaults. For more information about subscription options, send a "QUERY OSPF" command to LISTSERV@DISCUSS.MICROSOFT.COM. Contributions sent to this list are automatically archived. You can get a list of the available archive files by sending an "INDEX OSPF" command to LISTSERV@DISCUSS.MICROSOFT.COM. You can then order these files with a "GET OSPF LOGxxxx" command, or using LISTSERV's database search facilities. Send an "INFO DATABASE" command for more information on the latter. This list is available in digest form. If you wish to receive the digested version of the postings, just issue a SET OSPF DIGEST command. More information on LISTSERV commands can be found in the LISTSERV reference card, which you can retrieve by sending an "INFO REFCARD" command to LISTSERV@DISCUSS.MICROSOFT.COM. From MAILER-DAEMON Wed Apr 10 22:25:20 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08207 for ; Wed, 10 Apr 2002 22:25:20 -0400 (EDT) Message-Id: <200204110225.WAA08207@ietf.org> Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <9.FF43EE24@PEAR.EASE.LSOFT.COM>; Wed, 10 Apr 2002 22:25:21 -0500 Date: Wed, 10 Apr 2002 22:25:23 -0400 From: "L-Soft list server at DISCUSS.MICROSOFT.COM (1.8d)" Subject: Output of your job "ospf-archive" To: ospf-archive@ietf.org > subscribe ospf Anonymous You have been added to the OSPF list. Your subscription has been made anonymous; only the list owner will be able to see that you have joined the list. Please note however that posting to the list could reveal your name and e-mail address. In other words, you can only remain anonymous as long as you do not say anything on the list. Summary of resource utilization ------------------------------- CPU time: 0.000 sec Overhead CPU: 0.000 sec CPU model: ~1125MHz Pentium II 512k (1280M) Job origin: ospf-archive@LISTS.IETF.ORG From owner-ospf@DISCUSS.MICROSOFT.COM Thu Apr 11 07:34:16 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24439 for ; Thu, 11 Apr 2002 07:34:16 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <14.F5759FE1@PEAR.EASE.LSOFT.COM>; Thu, 11 Apr 2002 7:34:12 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 895084 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 11 Apr 2002 07:34:15 -0400 Received: from 212.59.42.147 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Thu, 11 Apr 2002 07:24:14 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: Question concerning the draft-katz-yeung-ospf-traffic Thread-Index: AcHhS2g4DMghw0xqSdCaRN7MoC0f7Q== Message-ID: Date: Thu, 11 Apr 2002 13:24:13 +0200 Reply-To: Mailing List Sender: Mailing List From: "Nelke, Jens" Subject: Question concerning the draft-katz-yeung-ospf-traffic To: OSPF@DISCUSS.MICROSOFT.COM Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA24439 Hi everybody, I am not sure if I understood the draft-katz-yeung-ospf-traffic right. Under 1.1 the author is speaking of monitoring the extended link attributes. Does this mean that the Routers will exchange data, about for instance the available bandwidth on their links? This would result in a LSDB based on unreserved bandwidth, but this Database would change as the amount of traffic through the node increases or decreases. Should the OSPF-TE react to these changes within the Database? Or should as an example RSVP tear down some less important paths (would be quicker than to run the CSPF)? I read in the draft that unnumbered links are not supported. I looked at the drafts to which the document pointed out. But I am still not sure, is it possible to use unnumbered links if the drafts OSPF-Extensions in Support of Generalized MPLS and Signalling Unnumbered Links in RSVP-TE are implemented? If not, is there any work done on this problem? It would be very helpful if anyone could give some advise on the topics addressed above. Regards Jens Nelke ------------------------------------------------------------------------ -------------------------- Dipl.-Ing. Jens Nelke Datentechnik Intercom GmbH Research&Development Frankenring 14, 30855 Langenhagen ------------------------------------------------------------------------ -------------------------- Tel.: +49 511 978197-657 Fax.: +49 511 978197-670 ------------------------------------------------------------------------ -------------------------- From owner-ospf@DISCUSS.MICROSOFT.COM Thu Apr 11 09:14:15 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26498 for ; Thu, 11 Apr 2002 09:14:14 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <1.FEA93115@PEAR.EASE.LSOFT.COM>; Thu, 11 Apr 2002 9:14:11 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 895291 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 11 Apr 2002 09:14:14 -0400 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Thu, 11 Apr 2002 09:14:13 -0500 Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g3BDE5T90036; Thu, 11 Apr 2002 06:14:05 -0700 (PDT) (envelope-from yakov@juniper.net) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <17591.1018530845.1@juniper.net> Message-ID: <200204111314.g3BDE5T90036@merlot.juniper.net> Date: Thu, 11 Apr 2002 06:14:05 -0700 Reply-To: Mailing List Sender: Mailing List From: Yakov Rekhter Subject: Re: LC comments on draft-ietf-ccamp-ospf-gmpls-extensions-05.txt Comments: To: Alex Zinin Comments: cc: ccamp@ops.ietf.org To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Your message of "Tue, 09 Apr 2002 13:04:50 PDT." <549063452.20020409130450@nexsi.com> Alex, > Kireeti, et al: > > Please find my comments on the draft below. > I'm also CC'ing the OSPF WG to make sure we > have a good coverage here. see my response in-line... > Cheers! > > Alex > > > CCAMP Working Group K. Kompella (Juniper Networks) > > Internet Draft Y. Rekhter (Juniper Networks) > > Expiration Date: October 2002 A. Banerjee (Calient Networks) > > J. Drake (Calient Networks) > > G. Bernstein (Ciena) > > D. Fedyk (Nortel Networks) > > E. Mannie (GTS Network) > > D. Saha (Tellium) > > V. Sharma (Metanoia, Inc.) > > I would consult your ADs about the length of the author list. > > IMHO, it's kind of hard to imagine 9 people editing > a draft containing 7 pages of useful info ;)) > > > > > OSPF Extensions in Support of Generalized MPLS > > > > draft-ietf-ccamp-ospf-gmpls-extensions-05.txt > > > > > [...] > > > > > 2. Abstract > > > > This document specifies encoding of extensions to the OSPF routing > > protocol in support of Generalized Multi-Protocol Label Switching > > (GMPLS). The description of the extensions is specified in [GMPLS- > > ROUTING]. > > The rfc-ed will request the citation to be removed from the abstract. I'll fix this in the next version of the draft. > > > > > 4. Introduction > > > > This document specifies extensions to the OSPF routing protocol in > > support of carrying link state information for Generalized Multi- > > Protocol Label Switching (GMPLS). The set of required enhancements to > > OSPF are outlined in [GMPLS-ROUTING]. > > It might be a good idea to explicitly mention that only > intra-area issues are covered here. That is not exactly correct, as the extensions defined in this document could certainly be used for establishing LSPs that span multiple area. An example of how this could be accomplished can be found in Section 4.1 of draft-kompella-mpls-multiarea-te-02.txt. > > 5. OSPF Routing Enhancements > > > > In this section we define the enhancements to the TE properties of > > GMPLS TE links that can be announced in OSPF TE LSAs. The Traffic > > Engineering (TE) LSA, which is an opaque LSA with area flooding scope > > [OSPF-TE], has only one top-level Type/Length/Value (TLV) triplet and > > has one or more nested sub-TLVs for extensibility. The top-level TLV > > can take one of two values (1) Router Address or (2) Link. In this > > document, we enhance the sub-TLVs for the Link TLV in support of > > GMPLS. Specifically, we add the following sub-TLVs to the Link TLV: > > > > 1. Link Local Identifier, > > 2. Link Remote Identifier, > > 3. Link Protection Type, > > 4. Interface Switching Capability Descriptor, and > > 5. Shared Risk Link Group. > > Minor: given the table below, do we need the above list really? Ok. I'll remove the list. > > The following defines the Type and Length of these sub-TLVs: > > > > Sub-TLV Type Length Name > > 11 4 Link Local Identifier > > 12 4 Link Remote Identifier > > 14 4 Link Protection Type > > 15 variable Interface Switching Capability Descriptor > > 16 variable Shared Risk Link Group > > > > [OSPF-TE] says: > > The Link Type and Link ID sub-TLVs are mandatory, i.e., must appear > exactly once. All other sub-TLVs defined here may occur at most > once. These restrictions need not apply to future sub-TLVs. > Unrecognized sub-TLVs are ignored. > > Considering the last two sentences, it would be really nice if > this document said something about this. > > You might also say something about processing of sub-TLVs > with unexpected length. Could you please suggest the text. > > 5.1. Link Local Identifier > > > > A Link Local Identifier is a sub-TLV of the Link TLV with type 11, > > and length 4. > > What do I put in it? Link Local Identifier. For more information consult Section 6.1 of draft-ietf-ccamp-gmpls-routing-03.txt. > > > 5.2. Link Remote Identifier > > > > A Link Remote Identifier is a sub-TLV of the Link TLV with type 12, > > and length 4. > > > > Ditto Link Remote Identifier. For more information consult Section 6.1 of draft-ietf-ccamp-gmpls-routing-03.txt. > > > > 5.3. Link Protection Type > > > > The Link Protection Type is a sub-TLV of the Link TLV, with type 14, > > and length of four octets, the first of which is a bit vector > > describing the protection capabilities of the link. They are: > > Might be a good idea to include an IETF-style format illustration > here, to make sure everyone understands "first octet" the same > way. I'll do this in the next version of the draft. > > Something should also be said about other octets. Ditto. > Are they reserved and ignored on receipt? Should be set to zero by the sender and should be ignored on receipt. > > > > 0x01 Extra Traffic > > > > 0x02 Unprotected > > > 0x04 Shared > > > > 0x08 Dedicated 1:1 > > > > 0x10 Dedicated 1+1 > > > > 0x20 Enhanced > > > > 0x40 Reserved > > > > 0x80 Reserved > > > > I believe these are described in [GMPLS-ROUTING]. You may want > to add a reference to it here. Will do in the next version of the draft. > > > 5.4. Shared Risk Link Group (SRLG) > > > > The SRLG is a sub-TLV of the Link TLV with type 16. The length is the > > length of the list in octets. The value is an unordered list of 32 > > bit numbers that are the SRLGs that the link belongs to. The format > > of the value field is as shown below: > > ditto ditto. > ... > > > 5.5. Interface Switching Capability Descriptor > > > > The Interface Switching Capability Descriptor is a sub-TLV of the > > Link TLV with type 15. The length is the length of value field in > > Minor: might want to change wording, not clear what "with type 15" is > relative to, one may ready "Link TLV with type 15". ditto. > > > octets. The format of the value field is as shown below: > > > ... > > > > When the Switching Capability field is PSC-1, PSC-2, PSC-3, or PSC-4, > > the specific information includes Interface MTU, Minimum LSP > > Bandwidth, and padding. The Interface MTU is encoded as a 2 octets > > integer. The Minimum LSP Bandwidth is is encoded in a 4 octets field > > in the IEEE floating point format. The units are bytes (not bits!) > > per second. The padding is 2 octets, and is used to make the > > Interface Switching Capability Descriptor sub-TLV 32-bits aligned. > > Would be just great to have a field format illustration here. ditto. > > > > > When the Switching Capability field is L2SC, there is no specific > > information. > > So, the field is not included? Please specify. Yes, there is no Switching Capability specific information field. I'll clarify this in the next version of the draft. > > When the Switching Capability field is TDM, the specific information > > includes Minimum LSP Bandwidth, an indication whether the interface > > supports Standard or Arbitrary SONET/SDH, and padding. The Minimum > > LSP Bandwidth is encoded in a 4 octets field in the IEEE floating > > point format. The units are bytes (not bits!) per second. The > > indication whether the interface supports Standard or Arbitrary > > SONET/SDH is encoded as 1 octet. The value of this octet is 0 if the > > interface supports Standard SONET/SDH, and 1 if the interface > > supports Arbitrary SONET/SDH. The padding is 3 octets, and is used > > to make the Interface Switching Capability Descriptor sub-TLV 32-bits > > aligned. > > Again, would appreciate a format illustration here. Breaking field > description into a list here and above would be nice as well. Will add to the next version of the draft. > > When the Switching Capability field is LSC, there is no specific > > information. > > "... and the field is not included." > > > > The Interface Switching Capability Descriptor sub-TLV may occur more > > than once within the Link TLV. > > "...to indicate multiple switching capabilities supported by the link. > The resulting set of capabilities includes all those announced in > multiple instances of the sub-TLV" or something like this? Ditto. > > > 6. Implications on Graceful Restart > > > > The restarting node should follow the OSPF restart procedures [OSPF- > > RESTART], and the RSVP-TE restart procedures [GMPLS-RSVP]. > > These look like normative references and hence it means that the > document will be delayed until those are complete. Just a heads-up :) Do you think it would be better to put TE Graceful Restart into a separate Internet Draft ? > > When a restarting node is going to originate its TE LSAs, the TE LSAs > > containing Link TLV should be originated with 0 unreserved bandwidth, > > and if the Link has LSC or FSC as its Switching Capability then also > > with 0 as Max LSP Bandwidth, until the node is able to determine the > > amount of unreserved resources taking into account the resources > > reserved by the already established LSPs that have been preserved > > across the restart. Once the restarting node determines the amount of > > unreserved resources, taking into account the resources reserved by > > the already established LSPs that have been preserved across the > > restart, the node should advertise these resources in its TE LSAs. > > > > In addition in the case of a planned restart prior to restarting, the > > restarting node SHOULD originate the TE LSAs containing Link TLV with > > 0 as unreserved bandwidth, and if the Link has LSC or FSC as its > > Switching Capability then also with 0 as Max LSP Bandwidth. > > "...to discourage new LSP establishment through the restarting router"? Will add to the next version of the draft. > > Neighbors of the restarting node should continue advertise the actual > > unreserved bandwidth on the TE links from the neighbors to that node. > > > > Regular graceful restart should not be aborted if a TE LSA or TE > > topology changes. TE graceful restart need not be aborted if a TE LSA > > or TE topology changes. > > > > > > 7. Security Considerations > > > > The sub-TLVs proposed in this document does not raise any new > > security concerns. > > "do not raise" Will fix in the next version of the draft. > > > > 9. References > > Might be a good idea to split these to normative and > informative or specify the type if all of them are the same > type. Ditto. Yakov. From owner-ospf@DISCUSS.MICROSOFT.COM Thu Apr 11 10:13:39 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27826 for ; Thu, 11 Apr 2002 10:13:38 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <5.F3EA56A1@PEAR.EASE.LSOFT.COM>; Thu, 11 Apr 2002 10:13:36 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 895483 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 11 Apr 2002 10:13:38 -0400 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Thu, 11 Apr 2002 10:13:38 -0500 Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g3BEDbT91750 for ; Thu, 11 Apr 2002 07:13:37 -0700 (PDT) (envelope-from kireeti@juniper.net) Received: (from kireeti@localhost) by kummer.juniper.net (8.11.6/8.11.6) id g3BEDbu61839 for OSPF@discuss.microsoft.com; Thu, 11 Apr 2002 07:13:37 -0700 (PDT) (envelope-from kireeti) Message-ID: <200204111413.g3BEDbu61839@kummer.juniper.net> Date: Thu, 11 Apr 2002 07:13:37 -0700 Reply-To: Mailing List Sender: Mailing List From: Kireeti Kompella Subject: Re: Question concerning the draft-katz-yeung-ospf-traffic To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: > I am not sure if I understood the draft-katz-yeung-ospf-traffic right. Not quite. > Does this mean that the Routers will exchange data, about > for instance the available bandwidth on their links? "Available" means "available to reserve". Reservations are usually fairly static. > This would result > in a LSDB based on unreserved bandwidth, but this Database would change > as the amount of traffic through the node increases or decreases. No, the TE database would only change when reservations change, i.e., LSPs went up/down/changed their reservations/changed their path. So, if an LSP _asked_ for 50 Mbps, but traffic over that LSP varied from 0-50 Mbps, the TE database would not be affected. If the LSP decided to up its bandwidth to 100, then there would be change. > I read in the draft that unnumbered links are not supported. More accurately, not described in *this* document. > But I am still not sure, > is it possible to use unnumbered links if the drafts OSPF-Extensions in > Support of Generalized MPLS and Signalling Unnumbered Links in RSVP-TE > are implemented? Yes. Kireeti. From owner-ospf@DISCUSS.MICROSOFT.COM Thu Apr 11 12:22:19 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04919 for ; Thu, 11 Apr 2002 12:22:18 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <1.FEA9312C@PEAR.EASE.LSOFT.COM>; Thu, 11 Apr 2002 12:22:16 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 896139 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 11 Apr 2002 12:22:18 -0400 Received: from 209.119.0.19 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Thu, 11 Apr 2002 12:22:18 -0500 Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <15.F6DC68F1@PEAR.EASE.LSOFT.COM>; Thu, 11 Apr 2002 12:22:16 -0500 Message-ID: Date: Thu, 11 Apr 2002 12:22:18 -0400 Reply-To: Mailing List Sender: Mailing List From: Manohar Naidu Ellanti Subject: draft-ietf-ospf-abr-alt-04.txt To: OSPF@DISCUSS.MICROSOFT.COM Is it possible that a router which is attached to multiple areas but not attached to area 0, can still be an ABR? For isntance, if a R1 has area 1,2 and 3 . Can it advertise summary-lsa for area 1 into 2 and 3 ? and similarly summary-lsa for 2 into 1 &3 etc. Both Cisco and IBM definition cited in the draft don't qualify a router as ABR unless it is attached to backbone. But isn't that restrictive if one knows that there is no real area 0 for some applications? Even if one were to have area 0, in the above example R1 might have an additional interface that is not connected to anything but configured with area id 0.0.0.0. The router may not have any adjacency over the backbone as there is no other router. -Ellanti From owner-ospf@DISCUSS.MICROSOFT.COM Thu Apr 11 15:25:31 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10673 for ; Thu, 11 Apr 2002 15:25:30 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <3.F8155B7E@PEAR.EASE.LSOFT.COM>; Thu, 11 Apr 2002 15:25:27 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 896649 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 11 Apr 2002 15:25:30 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Thu, 11 Apr 2002 15:25:30 -0500 Received: from redback.com (login003.redback.com [155.53.12.55]) by prattle.redback.com (Postfix) with ESMTP id F26111531D2 for ; Thu, 11 Apr 2002 12:25:27 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020205 X-Accept-Language: en-us MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3CB5E310.1040201@redback.com> Date: Thu, 11 Apr 2002 15:25:04 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: draft-ietf-ospf-abr-alt-04.txt To: OSPF@DISCUSS.MICROSOFT.COM Content-Transfer-Encoding: 7bit Manohar Naidu Ellanti wrote: > Is it possible that a router which is attached to multiple areas but not > attached to area 0, can still be an ABR? > > For isntance, if a R1 has area 1,2 and 3 . Can it advertise summary-lsa for > area 1 into 2 and 3 ? and similarly summary-lsa for 2 into 1 &3 etc. RFC 2328 defines an ABR as a router that is attached to two or more areas. By attached, it means it has at least one OSPF interface in the area in UP state. > > Both Cisco and IBM definition cited in the draft don't qualify a router as > ABR unless it is attached to backbone. Not exactly - anyway this why it is titled *alternate* ABR behavior. > But isn't that restrictive if one > knows that there is no real area 0 for some applications? If you have multiple areas, your network should contain a backbone. > Even if one were > to have area 0, in the above example R1 might have an additional interface > that is not connected to anything but configured with area id 0.0.0.0. The > router may not have any adjacency over the backbone as there is no other > router. This really isn't a valid network design - unless of course you're connecting to a BGP/MPLS VPN backbone (but that's a whole different story). > > -Ellanti > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Thu Apr 11 15:29:00 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10798 for ; Thu, 11 Apr 2002 15:28:59 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <12.FECFE5F7@PEAR.EASE.LSOFT.COM>; Thu, 11 Apr 2002 15:28:56 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 896677 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 11 Apr 2002 15:28:59 -0400 Received: from 63.236.75.8 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Thu, 11 Apr 2002 15:28:59 -0500 Received: by xmxpita.excite.com (Postfix, from userid 110) id 7AE55B728; Thu, 11 Apr 2002 15:28:54 -0400 (EDT) Received: from [10.50.6.217] by xprdmailfe18.nwk.excite.com via HTTP; Thu, 11 Apr 2002 15:28:54 EST MIME-Version: 1.0 X-Sender: dgoodspe@excite.com X-Mailer: PHP Content-Type: multipart/alternative; boundary="EXCITEBOUNDARY_000__09604e98eb46b60c365868cca7d30f17"; Content-Transfer-Encoding: 7bit Message-ID: <20020411192854.7AE55B728@xmxpita.excite.com> Date: Thu, 11 Apr 2002 15:28:54 -0400 Reply-To: Mailing List Sender: Mailing List From: Don Goodspeed Subject: Re: Summary's from backbone To: OSPF@DISCUSS.MICROSOFT.COM --EXCITEBOUNDARY_000__09604e98eb46b60c365868cca7d30f17 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sandor, Looping of packets can still occur in your second scenario in circumstances where costing has been modified. Let's assume router 6 sends the packet to router 3 due to costing that makes router 3 the closest exit point in area 1. The packet is destined for router 1, and router 3's best path to router 1 is via the virtual-link back thru area 1 via router 6. Oops, router 6 has router 3 as it's next-hop, and the loop occurs. If the virtual-link does not exist, router 3 has to send the packet to routers 7, then 5, then 1 (no loop). With no summarization, router 6 always learns the best path out of the area for each route in Area 0. -don --- On Wed 04/10, Sandor Ecker wrote: > Hi! > > Can anybody show me an example why is at the end of 12.4.3 this: > > "If an area is capable of carrying transit traffic, routing > information concerning backbone networks should not be > condensed before being summarysed into the area. ... In other > words, the backbone's ranges should be ignored..." > > I have one example, but i need an other one... > > My example: Here when a range were configured for A0, then router's > in > A1 could not decide the rigth way. (i'm right) > > +---+ > | 1 | > +---+ > | ttyS0 > | > | > | > | ttyS0 A0 > +---+ > --------------| 2 |----------------- > +---+ > eth2 /|\ eth1 > / | \ > / | \ > / | \ > /eth2| \ eth2 > +---+ | +---+ ttyS0 +---+ > | 6 | VL0 | 4 |-------------| 5 | > +---+ | +---+ ttyS0 +---+ > \ eth1 / eth1 > \ | / > \ | / > \ | / > eth2 \|/ eth1 A1 > +---+ > --------------| 3 |----------------- > +---+ > | ttyS0 > | > | > | > | ttyS0 A0 > +---+ > | 7 | > +---+ > > > Other example for the next topology: The R1-R5, and the R5-R7 links > are in A0 also, but the R4-R5 in A1. > > Here can anybody show me what were wrong, when the backbone would make > range summary to A1? > > > +---+ eth2 > | 1 |----------------------------------+ > +---+ | > | ttyS0 | > | | > | | > | | > | ttyS0 A0 | > +---+ | > --------------| 2 |------------------------------- | > +---+ | > eth2 /|\ eth1 | > / | \ | > / | \ | > / | \ |eth1 > /eth2| \ eth2 | > +---+ | +---+ ttyS0 +---+ > | 6 | VL0 | 4 |--------------------------| 5 | > +---+ | +---+ ttyS0 +---+ > \ eth1 / eth1 | > \ | / |eth2 > \ | / | > \ | / | > eth2 \|/ eth1 A1 | > +---+ | > --------------| 3 |------------------------------- | > +---+ | > | ttyS0 | > | | > | | > | | > | ttyS0 A0 | > +---+ | > | 7 |----------------------------------+ > +---+ eth1 > > Why don't need to make so restriction for an non backbone area, just for > backbone? > > > Regards, > Sandor Ecker > ------------------------------------------------ --EXCITEBOUNDARY_000__09604e98eb46b60c365868cca7d30f17 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit Sandor,

Looping of packets can still occur in your second scenario
in circumstances where costing has been modified.

Let's assume router 6 sends the packet to router 3 due to
costing that makes router 3 the closest exit point in area 1.

The packet is destined for router 1, and router 3's best path
to router 1 is via the virtual-link back thru area 1 via router
6. Oops, router 6 has router 3 as it's next-hop, and the
loop occurs. If the virtual-link does not exist, router 3
has to send the packet to routers 7, then 5, then 1 (no loop).

With no summarization, router 6 always learns the best path
out of the area for each route in Area 0.

-don


--- On Wed 04/10, Sandor Ecker wrote:
> Hi!
>
> Can anybody show me an example why is at the end of 12.4.3 this:
>
> "If an area is capable of carrying transit traffic, routing
> information concerning backbone networks should not be
> condensed before being summarysed into the area. ... In other
> words, the backbone's ranges should be ignored..."
>
> I have one example, but i need an other one...
>
> My example: Here when a range were configured for A0, then router's
> in
> A1 could not decide the rigth way. (i'm right)
>
> +---+
> | 1 |
> +---+
> | ttyS0
> |
> |
> |
> | ttyS0 A0
> +---+
> --------------| 2 |-----------------
> +---+
> eth2 /|\ eth1
> / | \
> / | \
> / | \
> /eth2| \ eth2
> +---+ | +---+ ttyS0 +---+
> | 6 | VL0 | 4 |-------------| 5 |
> +---+ | +---+ ttyS0 +---+
> \ eth1 / eth1
> \ | /
> \ | /
> \ | /
> eth2 \|/ eth1 A1
> +---+
> --------------| 3 |-----------------
> +---+
> | ttyS0
> |
> |
> |
> | ttyS0 A0
> +---+
> | 7 |
> +---+
>
>
> Other example for the next topology: The R1-R5, and the R5-R7 links
> are in A0 also, but the R4-R5 in A1.
>
> Here can anybody show me what were wrong, when the backbone would make
> range summary to A1?
>
>
> +---+ eth2
> | 1 |----------------------------------+
> +---+ |
> | ttyS0 |
> | |
> | |
> | |
> | ttyS0 A0 |
> +---+ |
> --------------| 2 |------------------------------- |
> +---+ |
> eth2 /|\ eth1 |
> / | \ |
> / | \ |
> / | \ |eth1
> /eth2| \ eth2 |
> +---+ | +---+ ttyS0 +---+
> | 6 | VL0 | 4 |--------------------------| 5 |
> +---+ | +---+ ttyS0 +---+
> \ eth1 / eth1 |
> \ | / |eth2
> \ | / |
> \ | / |
> eth2 \|/ eth1 A1 |
> +---+ |
> --------------| 3 |------------------------------- |
> +---+ |
> | ttyS0 |
> | |
> | |
> | |
> | ttyS0 A0 |
> +---+ |
> | 7 |----------------------------------+
> +---+ eth1
>
> Why don't need to make so restriction for an non backbone area, just for
> backbone?
>
>
> Regards,
> Sandor Ecker
>

--EXCITEBOUNDARY_000__09604e98eb46b60c365868cca7d30f17-- From owner-ospf@DISCUSS.MICROSOFT.COM Thu Apr 11 19:04:45 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19073 for ; Thu, 11 Apr 2002 19:04:44 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <1.FEA93146@PEAR.EASE.LSOFT.COM>; Thu, 11 Apr 2002 19:04:41 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 874974 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 11 Apr 2002 19:04:44 -0400 Received: from 66.35.207.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Thu, 11 Apr 2002 19:04:43 -0400 Received: from khonsu.Winnet.NEXSI.NET (khonsu.winnet.nexsi.net [192.168.104.132]) by chrome.nexsi.com (Postfix) with ESMTP id 7CB2BF02E; Thu, 11 Apr 2002 16:04:34 -0700 (PDT) X-Mailer: The Bat! (v1.60c) Personal X-Priority: 3 (Normal) References: <200204111314.g3BDE5T90036@merlot.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <1192435487.20020411160045@nexsi.com> Date: Thu, 11 Apr 2002 16:00:45 -0700 Reply-To: Mailing List Sender: Mailing List From: Alex Zinin Organization: Nexsi Systems Subject: Re: LC comments on draft-ietf-ccamp-ospf-gmpls-extensions-05.txt Comments: To: Yakov Rekhter Comments: cc: ccamp@ops.ietf.org To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <200204111314.g3BDE5T90036@merlot.juniper.net> Content-Transfer-Encoding: 7bit Yakov, Thanks for the follow up. See below, pls. >> It might be a good idea to explicitly mention that only >> intra-area issues are covered here. > That is not exactly correct, as the extensions defined in this > document could certainly be used for establishing LSPs that span > multiple area. An example of how this could be accomplished can > be found in Section 4.1 of draft-kompella-mpls-multiarea-te-02.txt. OK, I see what you mean. What I meant is that the document does not described any sort of aggregation and distribution of introduced parameters between areas. >> [OSPF-TE] says: >> >> The Link Type and Link ID sub-TLVs are mandatory, i.e., must appear >> exactly once. All other sub-TLVs defined here may occur at most >> once. These restrictions need not apply to future sub-TLVs. >> Unrecognized sub-TLVs are ignored. >> >> Considering the last two sentences, it would be really nice if >> this document said something about this. >> >> You might also say something about processing of sub-TLVs >> with unexpected length. > Could you please suggest the text. If I may, I would leave the exact wording to the authors, please. I would, however, be willing to review proposed text. >> > 5.1. Link Local Identifier >> > >> > A Link Local Identifier is a sub-TLV of the Link TLV with type 11, >> > and length 4. >> >> What do I put in it? > Link Local Identifier. For more information consult Section 6.1 > of draft-ietf-ccamp-gmpls-routing-03.txt. Please specify in the draft (though the names happen to be the same). >> > 5.2. Link Remote Identifier >> > >> > A Link Remote Identifier is a sub-TLV of the Link TLV with type 12, >> > and length 4. >> > >> >> Ditto > Link Remote Identifier. For more information consult Section 6.1 > of draft-ietf-ccamp-gmpls-routing-03.txt. Ditto >> > 5.3. Link Protection Type >> > >> > The Link Protection Type is a sub-TLV of the Link TLV, with type 14, >> > and length of four octets, the first of which is a bit vector >> > describing the protection capabilities of the link. They are: >> >> Something should also be said about other octets. > Ditto. >> Are they reserved and ignored on receipt? > Should be set to zero by the sender and should be ignored on receipt. Please specify as well. Thanks a lot! Alex From owner-ospf@DISCUSS.MICROSOFT.COM Thu Apr 11 19:24:51 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19868 for ; Thu, 11 Apr 2002 19:24:48 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <12.FECFE604@PEAR.EASE.LSOFT.COM>; Thu, 11 Apr 2002 19:24:44 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 875011 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 11 Apr 2002 19:24:46 -0400 Received: from 207.217.120.84 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Thu, 11 Apr 2002 19:24:46 -0400 Received: from user-2ivfm7g.dialup.mindspring.com ([165.247.216.240] helo=earthlink.net) by gull.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16vnvp-0004kC-00 for ospf@discuss.microsoft.com; Thu, 11 Apr 2002 16:24:45 -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 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3CB61CF7.45CBE0E6@earthlink.net> Date: Thu, 11 Apr 2002 16:32:07 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: reservations versus resources, te extensions, etc.. To: OSPF@DISCUSS.MICROSOFT.COM Content-Transfer-Encoding: 7bit ... draft-katz-yeung-ospf-traffic-06.txt Group, I have a few (7) fairly fundamental questions here.. Sorry about the lateness of this email. I am just trying to figure out how to support these extensions... Mitchell Erblich --------------------- 1) 1a) "in this direction" used in 2.5.6 and 2.5.7, and not used in 2.5.8. I assume we are thinking from the router's interface. Since we aren't using this phrase in 2.5.8, is this value non-direction specific? 1b) I assume that the link atributes are direction specific from the perspective of a router's interface. Thus, I assume we can have two different values for the 2.5.6 Maximum Bandwidth. In the case of Ethernet, etc, should we verify that all Opaque speaking OSPF routers using the link "agree" on the same value? Especially with Ethenernet? Can one believe that the link is a 10Mb link and another believe it is a 100Mb link? Be neighbors, form an adjacency? 2) 1.2 Limitations "The reservation state of multiaccess links is not accurately reflected, except in the special case that there are only two devices in the multiaccess subnetwork." Given this fact. Is there a special set of events that should occur in case both devices datagrams collide? Simply, should the router treat retransmission of datagrams as additional consumption of bandwidth that was reserved or as part of the original bandwidth allocation? 3) There is no discussion on how one would be expected to set-up reservation for example, fair-weighted queueing support. 4) Just because we reserve bandwidth in one direction (out), there is no discussion that we will be able to forward a datagram, etc because we have not done any input allocations. Actually, I don't see how we can do this input type of allocation! 5) 2.5.7 Are we to assume that oversubscription is not a problem because only under extreme congestion, may the lower priority reservations not be fulfilled? Why not state that? 6) 4.0 Compatibility issues.. 6a) Can't the values of these opaque LSAs be used to determine best paths? If one network is comprised of a set of heterogenous routers (opaque capable and not), then each capable type of router could determine a different path. Shouldn't this lead to blackholes and routing loops? Couldn't a lower memory supported router (also less Mips capable) with opaque LSA capability be expected to consume more memory, more link bandwidth, take longer to achieve adjacencies, and possibly not perform as expected. 6b) But there is no discussion, that low priority datagrams that overfill their output queues (2.5.8) due to low-reservations should even be dropped when the router is congested. Should their be primary and secondary congestion disscussions? 7) With all the discusion of bandwidth allocations, why couldn't we support a TLV / Sub-TLV with a congestion (i.e. IS-IS overload binary value), that would be set by the router when it is under congestion (dropping a significant number of datagrams due to "RED")? From owner-ospf@DISCUSS.MICROSOFT.COM Thu Apr 11 20:05:52 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20659 for ; Thu, 11 Apr 2002 20:05:51 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <4.F02EE824@PEAR.EASE.LSOFT.COM>; Thu, 11 Apr 2002 20:05:48 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 875065 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 11 Apr 2002 20:05:51 -0400 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Thu, 11 Apr 2002 20:05:50 -0400 Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g3C05oT32491 for ; Thu, 11 Apr 2002 17:05:50 -0700 (PDT) (envelope-from kireeti@juniper.net) Received: (from kireeti@localhost) by kummer.juniper.net (8.11.6/8.11.6) id g3C05oX63656 for OSPF@discuss.microsoft.com; Thu, 11 Apr 2002 17:05:50 -0700 (PDT) (envelope-from kireeti) Message-ID: <200204120005.g3C05oX63656@kummer.juniper.net> Date: Thu, 11 Apr 2002 17:05:50 -0700 Reply-To: Mailing List Sender: Mailing List From: Kireeti Kompella Subject: Re: reservations versus resources, te extensions, etc.. To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3CB61CF7.45CBE0E6@earthlink.net> > 1a) "in this direction" used in 2.5.6 and 2.5.7, > and not used in 2.5.8. I assume we are thinking > from the router's interface. Since we aren't > using this phrase in 2.5.8, is this value > non-direction specific? Nope, unreserved bandwidth is direction specific. > 1b) > I assume that the link atributes are direction specific > from the perspective of a router's interface. Thus, I assume > we can have two different values for the 2.5.6 Maximum Bandwidth. And you can have two different values of the "regular" SPF metric, and have asymmetric routing. You can do it, but not everyone will be happy .... > In the case of Ethernet, etc, should we verify that all Opaque > speaking OSPF routers using the link "agree" on the same value? No particular reason to do so. > "The reservation state of multiaccess > links is not accurately reflected, except in the special case that > there are only two devices in the multiaccess subnetwork." > > Given this fact. Is there a special set of events that should > occur in case both devices datagrams collide? Simply, should the > router treat retransmission of datagrams as additional consumption of > bandwidth that was reserved or as part of the original bandwidth > allocation? The issue is not datagram collision, but call admission control. > 3) There is no discussion on how one would be expected to > set-up reservation for example, fair-weighted queueing support. That's because "fair-weighted queueing" is not in the scope of this document. The Diff-Serv TE work comes a little bit closer. > 4) Just because we reserve bandwidth in one direction (out), there is no > discussion that we will be able to forward a datagram, etc > because we have not done any input allocations. Actually, > I don't see how we can do this input type of allocation! Again, not in scope. > 5) 2.5.7 Are we to assume that oversubscription is not a problem > because only under extreme congestion, may the lower priority > reservations not be fulfilled? Why not state that? Oversubscription is all about stat mux. If someone can't live with that, they shouldn't oversubscribe. > 7) With all the discusion of bandwidth allocations, why couldn't > we support a TLV / Sub-TLV with a congestion (i.e. IS-IS overload > binary value), that would be set by the router when it is under > congestion (dropping a significant number of datagrams due to > "RED")? Bandwidth in the context of OSPF and IS-IS TE is all about *reservations* not about instantaneous utilization of a link. Kireeti. From owner-ospf@DISCUSS.MICROSOFT.COM Fri Apr 12 04:39:20 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21673 for ; Fri, 12 Apr 2002 04:39:20 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <7.FEBE4AD0@PEAR.EASE.LSOFT.COM>; Fri, 12 Apr 2002 4:39:17 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 876021 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 12 Apr 2002 04:39:20 -0400 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Fri, 12 Apr 2002 04:39:20 -0400 Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g3C8dJT48905; Fri, 12 Apr 2002 01:39:19 -0700 (PDT) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.11.6/8.11.6) with ESMTP id g3C8dIi64921; Fri, 12 Apr 2002 01:39:18 -0700 (PDT) (envelope-from kireeti@juniper.net) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: <20020412013354.X64564-100000@kummer.juniper.net> Date: Fri, 12 Apr 2002 01:39:18 -0700 Reply-To: Mailing List Sender: Mailing List From: Kireeti Kompella Subject: Re: LC comments on draft-ietf-ccamp-ospf-gmpls-extensions-05.txt Comments: To: Zafar Ali Comments: cc: Yakov Rekhter , abanerjee@calient.net, jdrake@calient.net, greg@ciena.com, dwfedyk@nortelnetworks.com, eric.mannie@gtsgroup.com, dsaha@tellium.com, v.sharma@ieee.org, ccamp@ops.ietf.org To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <4.3.2.7.2.20020412013258.046b6e78@sword.cisco.com> On Fri, 12 Apr 2002, Zafar Ali wrote: > A way of exchanging the Link Identifiers for Unnumbered TE links (with > interface switching cap of PSC-1 to PSC-4) is missing from the draft. In > ISIS, the unnumbered TE link identifiers can be exchanged using Link > Identifies in the Extended Local Circuit ID field of the "Point-to-Point > Three-Way Adjacency" IS-IS Option type [draft-ietf-isis-3way-05.txt]. Can > you please define an equivalent mechanism for the OSPF in the draft? Excellent point. We have a way of doing this (namely, a link-local opaque LSA, similar to grace-LSAs), but we weren't sure whether to put it in this draft or a companion draft. To keep the parallelism with the ISIS draft, we should probably just add this specification to this draft ... Kireeti. From owner-ospf@DISCUSS.MICROSOFT.COM Tue Apr 16 08:59:30 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01250 for ; Tue, 16 Apr 2002 08:59:30 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <8.E6B6738D@PEAR.EASE.LSOFT.COM>; Tue, 16 Apr 2002 8:59:15 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 889066 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 16 Apr 2002 08:59:25 -0400 Received: from 204.68.180.54 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Tue, 16 Apr 2002 08:59:25 -0400 Received: from mail.hq.tellabs.com (mail.bb.tellabs.com [138.111.51.100]) by mx4.tellabs.com (Mirapoint) with ESMTP id ADA45881; Tue, 16 Apr 2002 07:58:31 -0500 (CDT) Received: from localhost (root@localhost) by mail.hq.tellabs.com (8.8.6 (PHNE_17190)/8.8.6) with ESMTP id HAA26657 for ; Tue, 16 Apr 2002 07:58:32 -0500 (CDT) X-OpenMail-Hops: 1 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="MIRAPOINT_PART1_3cbc1ff7" Message-ID: Date: Tue, 16 Apr 2002 07:58:31 -0500 Reply-To: Mailing List Sender: Mailing List From: Jeff Richards Subject: Numbered/unnumbered links To: OSPF@DISCUSS.MICROSOFT.COM --MIRAPOINT_PART1_3cbc1ff7 Content-Type: multipart/alternative; boundary=openmail-part-2de6a390-00000002 --openmail-part-2de6a390-00000002 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline ;Creation-Date="Tue, 16 Apr 2002 07:58:31 -0500" Content-Transfer-Encoding: 8bit I have a couple of questions that I have not been able to figure out. 1. What are the pros and cons of using numbered or unnumbered interfaces. Why choose one over the other? 2. I know this next question is not particulally appropriate for this group, so please forgive me How is an unnumbered interface assigned to an area? Thanks in advance for your responses. Jeff --openmail-part-2de6a390-00000002 Content-Type: application/rtf Content-Disposition: attachment; filename="BDY.RTF" ;Creation-Date="Tue, 16 Apr 2002 07:58:31 -0500" Content-Transfer-Encoding: base64 e1xydGYxXGFuc2lcYW5zaWNwZzEyNTJcZGVmZjBcZGVmbGFuZzEwMzN7XGZvbnR0Ymx7XGYw XGZzd2lzc1xmY2hhcnNldDAgQXJpYWw7fX0NClx2aWV3a2luZDRcdWMxXHBhcmRcZjBcZnMy MCBJIGhhdmUgYSBjb3VwbGUgb2YgcXVlc3Rpb25zIHRoYXQgSSBoYXZlIG5vdCBiZWVuIGFi bGUgdG8gZmlndXJlIG91dC5ccGFyDQpccGFyDQoxLiBXaGF0IGFyZSB0aGUgcHJvcyBhbmQg Y29ucyBvZiB1c2luZyBudW1iZXJlZCBvciB1bm51bWJlcmVkIGludGVyZmFjZXMuIFdoeSBj aG9vc2Ugb25lIG92ZXIgdGhlIG90aGVyP1xwYXINClxwYXINCjIuIEkga25vdyB0aGlzIG5l eHQgcXVlc3Rpb24gaXMgbm90IHBhcnRpY3VsYWxseSBhcHByb3ByaWF0ZSBmb3IgdGhpcyBn cm91cCwgc28gcGxlYXNlIGZvcmdpdmUgbWVccGFyDQpccGFyDQpIb3cgaXMgYW4gdW5udW1i ZXJlZCBpbnRlcmZhY2UgYXNzaWduZWQgdG8gYW4gYXJlYT9ccGFyDQpccGFyDQpUaGFua3Mg aW4gYWR2YW5jZSBmb3IgeW91ciByZXNwb25zZXMuXHBhcg0KXHBhcg0KSmVmZiBccGFyDQp9 DQoA --openmail-part-2de6a390-00000002-- --MIRAPOINT_PART1_3cbc1ff7 Content-type: text/plain Content-Disposition: inline ============================================================ The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs ============================================================ --MIRAPOINT_PART1_3cbc1ff7-- From owner-ospf@DISCUSS.MICROSOFT.COM Tue Apr 16 09:09:18 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01474 for ; Tue, 16 Apr 2002 09:09:17 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <9.FF43F08D@PEAR.EASE.LSOFT.COM>; Tue, 16 Apr 2002 9:09:08 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 889108 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 16 Apr 2002 09:09:18 -0400 Received: from 192.11.223.163 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Tue, 16 Apr 2002 09:09:18 -0400 Received: from nj7460exch002h.wins.lucent.com (h135-17-42-35.lucent.com [135.17.42.35]) by auemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g3GD9Ha13012 for ; Tue, 16 Apr 2002 09:09:17 -0400 (EDT) Received: by nj7460exch002h.ho.lucent.com with Internet Mail Service (5.5.2653.19) id <20N5TNTY>; Tue, 16 Apr 2002 09:09:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <1BE55F80D32C204894F0E65A45C776CC1A9554@nj7460exch006u.ho.lucent.com> Date: Tue, 16 Apr 2002 09:09:14 -0400 Reply-To: Mailing List Sender: Mailing List From: "Jiang, Donghua (Jane)" Subject: Re: Numbered/unnumbered links To: OSPF@DISCUSS.MICROSOFT.COM Jeff, Unnumbered interfaces are used to save IP addresses. We don't need to assign them IP addresses. Regards, Jane -----Original Message----- From: Jeff Richards [mailto:jeff.richards@TELLABS.COM] Sent: Tuesday, April 16, 2002 5:59 AM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Numbered/unnumbered links I have a couple of questions that I have not been able to figure out. 1. What are the pros and cons of using numbered or unnumbered interfaces. Why choose one over the other? 2. I know this next question is not particulally appropriate for this group, so please forgive me How is an unnumbered interface assigned to an area? Thanks in advance for your responses. Jeff From owner-ospf@DISCUSS.MICROSOFT.COM Tue Apr 16 09:28:49 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02690 for ; Tue, 16 Apr 2002 09:28:48 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <8.E6B6738F@PEAR.EASE.LSOFT.COM>; Tue, 16 Apr 2002 9:28:38 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 889142 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 16 Apr 2002 09:28:48 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Tue, 16 Apr 2002 09:28:48 -0400 Received: from redback.com (login003.redback.com [155.53.12.55]) by prattle.redback.com (Postfix) with ESMTP id 35C10CAB71 for ; Tue, 16 Apr 2002 06:28:47 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020205 X-Accept-Language: en-us MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3CBC26B9.1090300@redback.com> Date: Tue, 16 Apr 2002 09:27:21 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Numbered/unnumbered links To: OSPF@DISCUSS.MICROSOFT.COM Content-Transfer-Encoding: 7bit Jeff Richards wrote: > I have a couple of questions that I have not been able to figure out. > > 1. What are the pros and cons of using numbered or unnumbered > interfaces. Why choose one over the other? Jeff, With respect to unnumbered interfaces: Pros: You don't have to assign an IP address. Another argument I've heard is that you don't have the overhead of DNS administration. This assumes a policy that all addresses must have DNS names and I think it is lame. Cons: You can't directly ping an unnumbered interface. It also won't be contained in traceroute output. Your managment tools will have to identify it using the ifIndex. If it were my network I'd use numbered interfaces unless I was *really* short on addresses. > > 2. I know this next question is not particulally appropriate for this > group, so please forgive me > > How is an unnumbered interface assigned to an area? This is implementation specific. With our implementation you simply specify the logical interface name of the unnumbered interface. router ospf 1 area 0 interface unnumbered-POS1 interface unnumbered-POS2 > > Thanks in advance for your responses. > > Jeff > > > > ------------------------------------------------------------------------ > > ============================================================ > The information contained in this message may be privileged > and confidential and protected from disclosure. If the > reader of this message is not the intended recipient, or an > employee or agent responsible for delivering this message to > the intended recipient, you are hereby notified that any > reproduction, dissemination or distribution of this > communication is strictly prohibited. If you have received > this communication in error, please notify us immediately by > replying to the message and deleting it from your computer. > > Thank you. > Tellabs > ============================================================ > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Mon Apr 22 20:45:12 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19327 for ; Mon, 22 Apr 2002 20:45:11 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <15.F6DC6CEF@PEAR.EASE.LSOFT.COM>; Mon, 22 Apr 2002 20:44:55 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 906525 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 22 Apr 2002 20:45:12 -0400 Received: from 64.4.37.48 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Mon, 22 Apr 2002 20:35:12 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 22 Apr 2002 17:35:11 -0700 Received: from 155.245.254.253 by pv2fd.pav2.hotmail.msn.com with HTTP; Tue, 23 Apr 2002 00:35:11 GMT X-Originating-IP: [155.245.254.253] Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 23 Apr 2002 00:35:11.0429 (UTC) FILETIME=[BA2AFF50:01C1EA5E] Message-ID: Date: Tue, 23 Apr 2002 00:35:11 +0000 Reply-To: Mailing List Sender: Mailing List From: wu min Subject: Route Aggregation To: OSPF@DISCUSS.MICROSOFT.COM Hi, I have some questions and I hope someone out there can help. 1) I understand that when a router tries to route a packet it must use the packet's destination address to search for the longest match prefix entry in it routing table to determine how and where the packet is supposed to be forwarded. Supposely the router break this rule and use a prefix which is not the longest match regardless of the existent of a longer one, what would be the consequences assuming that the next hop router for the chosen prefix is different from the longest match prefix? Is this safe? 2) Does OSPF perform route aggregation as BGP? If yes, then is it automatic or have to be manually configured? 3) A router running certain distributed routing protocol receives link state advertisements about other routers. When it tries to build a routing table it found out that several prefixes in which one is a subset of the other. In addition it found that all the prefixes have similar next hop router. Is it allowable for these prefixes to be aggregated and assigned with a prefix with the most general one? To clarify my question, let me use one example. Given that a router has the following fictious routing information: i) prefix = 10.2.153.178/32; next-hop = router2 ii) prefix = 10.2.153/23; next-hop = router2 iii) prefix = 10.2.154/23; next-hop = router2 iv) prefix = 10.2/16; next-hop = router2 The question is, is it possible to aggregate them such that we have only the following prefix in the routing table? iv) prefix = 10.2/16; next-hop = router2 I would be very much appreciated if someone could clear my doubt. Thanx. -Tze Ven _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx From owner-ospf@DISCUSS.MICROSOFT.COM Tue Apr 23 02:18:42 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07368 for ; Tue, 23 Apr 2002 02:18:41 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <8.E6B675C2@PEAR.EASE.LSOFT.COM>; Tue, 23 Apr 2002 2:18:24 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 907327 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 23 Apr 2002 02:18:41 -0400 Received: from 202.54.64.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Tue, 23 Apr 2002 02:18:40 -0400 Received: by GANESH with Internet Mail Service (5.5.2653.19) id ; Tue, 23 Apr 2002 11:56:16 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Tue, 23 Apr 2002 11:46:55 +0530 Reply-To: Mailing List Sender: Mailing List From: "Balaji R (Networking) - CTD, Chennai." Subject: Re: Route Aggregation To: OSPF@DISCUSS.MICROSOFT.COM -----Original Message----- From: wu min [mailto:made_in__china@HOTMAIL.COM] Sent: Tuesday, April 23, 2002 6:05 AM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Route Aggregation Hi, I have some questions and I hope someone out there can help. 1) I understand that when a router tries to route a packet it must use the packet's destination address to search for the longest match prefix entry in it routing table to determine how and where the packet is supposed to be forwarded. Supposely the router break this rule and use a prefix which is not the longest match regardless of the existent of a longer one, what would be the consequences assuming that the next hop router for the chosen prefix is different from the longest match prefix? Is this safe? Not all the time. If the other router thinks that you are the next hop for the longer prefix, this will result in a routing loop. 2) Does OSPF perform route aggregation as BGP? If yes, then is it automatic or have to be manually configured? Yes, OSPF performs route aggregation at area boundaries and during redistribution of routes from other routing protocols. The address ranges that are to be aggregated are manually configured as per RFC 2328. I don't know the implications of doing it dynamically. Can someone throw more light on this? 3) A router running certain distributed routing protocol receives link state advertisements about other routers. When it tries to build a routing table it found out that several prefixes in which one is a subset of the other. In addition it found that all the prefixes have similar next hop router. Is it allowable for these prefixes to be aggregated and assigned with a prefix with the most general one? To clarify my question, let me use one example. Given that a router has the following fictious routing information: i) prefix = 10.2.153.178/32; next-hop = router2 ii) prefix = 10.2.153/23; next-hop = router2 iii) prefix = 10.2.154/23; next-hop = router2 iv) prefix = 10.2/16; next-hop = router2 The question is, is it possible to aggregate them such that we have only the following prefix in the routing table? iv) prefix = 10.2/16; next-hop = router2 Are you talking about External-LSA's here? If so, it is better not to aggregate as the intent of the sender might to update just the LSA that changes. (Otherwise, the sender would have probably aggregated the routes). If you aggregated, you wouldn't be able to do incremental routing table calculation. I would be very much appreciated if someone could clear my doubt. Thanx. -Tze Ven _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx From owner-ospf@DISCUSS.MICROSOFT.COM Tue Apr 23 08:12:35 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13775 for ; Tue, 23 Apr 2002 08:12:34 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <11.F9E55EB1@PEAR.EASE.LSOFT.COM>; Tue, 23 Apr 2002 8:12:18 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 908237 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 23 Apr 2002 08:12:35 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Tue, 23 Apr 2002 08:12:35 -0400 Received: from redback.com (login002.redback.com [155.53.12.54]) by prattle.redback.com (Postfix) with ESMTP id 2B90EF2C47 for ; Tue, 23 Apr 2002 05:12:34 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020205 X-Accept-Language: en-us MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3CC54F00.50500@redback.com> Date: Tue, 23 Apr 2002 08:09:36 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Route Aggregation To: OSPF@DISCUSS.MICROSOFT.COM Content-Transfer-Encoding: 7bit wu min wrote: > Hi, > > I have some questions and I hope someone out there can help. > > 1) I understand that when a router tries to route a packet it must use the > packet's destination address to search for the longest match prefix entry > in it routing table to determine how and where the packet is supposed to be > forwarded. Supposely the router break this rule and use a prefix which is > not the longest match regardless of the existent of a longer one, what > would > be the consequences assuming that the next hop router for the chosen prefix > is different from the longest match prefix? Is this safe? This was changed. OSPF routers will always use the longest prefix match (discounting other forwarding tricks). Refer to appendix G.5 in RFC 2328. > > 2) Does OSPF perform route aggregation as BGP? If yes, then is it automatic > or have to be manually configured? OSPF and BGP aggregation are quite different. OSPF will summarise the routes within an area via configured area ranges. This will result in an aggregation of sorts. > > 3) A router running certain distributed routing protocol receives link > state > advertisements about other routers. When it tries to build a routing table > it found out that several prefixes in which one is a subset of the > other. In > addition it found that all the prefixes have similar next hop router. Is it > allowable for these prefixes to be aggregated and assigned with a prefix > with the most general one? To clarify my question, let me use one example. > Given that a router has the following fictious routing information: > > i) prefix = 10.2.153.178/32; next-hop = router2 > ii) prefix = 10.2.153/23; next-hop = router2 > iii) prefix = 10.2.154/23; next-hop = router2 > iv) prefix = 10.2/16; next-hop = router2 > > The question is, is it possible to aggregate them such that we have only > the > following prefix in the routing table? > > iv) prefix = 10.2/16; next-hop = router2 OSPF will install all 4 routes. In fact, I believe BGP will install all 4 routes as well (although it may advertise an aggregated route to its peers). > > I would be very much appreciated if someone could clear my doubt. > Thanx. > > -Tze Ven > > _________________________________________________________________ > MSN Photos is the easiest way to share and print your photos: > http://photos.msn.com/support/worldwide.aspx > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Tue Apr 23 10:32:57 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19618 for ; Tue, 23 Apr 2002 10:32:56 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <10.F8E03F7C@PEAR.EASE.LSOFT.COM>; Tue, 23 Apr 2002 10:32:40 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 908943 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 23 Apr 2002 10:32:57 -0400 Received: from 216.57.132.42 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Tue, 23 Apr 2002 10:32:57 -0400 MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3CC57098.3080609@sandburst.com> Date: Tue, 23 Apr 2002 10:32:56 -0400 Reply-To: Mailing List Sender: Mailing List From: Eric Gray Subject: Re: Route Aggregation To: OSPF@DISCUSS.MICROSOFT.COM Content-Transfer-Encoding: 7bit Balaji R (Networking) - CTD, Chennai. wrote: >-----Original Message----- >From: wu min [mailto:made_in__china@HOTMAIL.COM] >Sent: Tuesday, April 23, 2002 6:05 AM >To: OSPF@DISCUSS.MICROSOFT.COM >Subject: Route Aggregation > >Hi, > >I have some questions and I hope someone out there can help. > >1) I understand that when a router tries to route a packet it must use the >packet's destination address to search for the longest match prefix entry >in it routing table to determine how and where the packet is supposed to be >forwarded. Supposely the router break this rule and use a prefix which is >not the longest match regardless of the existent of a longer one, what would >be the consequences assuming that the next hop router for the chosen prefix >is different from the longest match prefix? Is this safe? > Not all the time. If the other router thinks that you are the next >hop for the longer prefix, this will result in a routing loop. > I doubt that this is ever 'safe' - though you may get away with it. In order to get away with it, other routers must not have a preferred route such that the packet will subsequently arrive at the same router. The case where the peer router thinks the local router is the next hop will not often result in a routing loop - it would be a black hole instead - because 'split- horizon' behavior will prevent it from returning the packet to the router from which it has received it. But there are a ton of other ways in which the packet may end up arriving at the local router again, resulting in a loop. > > >... > -- -- Eric Gray (mailto:eric.gray@sandburst.com) http://www.mindspring.com/~ewgray From owner-ospf@DISCUSS.MICROSOFT.COM Tue Apr 23 10:46:36 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20218 for ; Tue, 23 Apr 2002 10:46:35 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <8.E6B675F9@PEAR.EASE.LSOFT.COM>; Tue, 23 Apr 2002 10:46:19 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 909067 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 23 Apr 2002 10:46:36 -0400 Received: from 202.54.64.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Tue, 23 Apr 2002 10:46:36 -0400 Received: by GANESH with Internet Mail Service (5.5.2653.19) id ; Tue, 23 Apr 2002 20:24:10 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Tue, 23 Apr 2002 20:14:50 +0530 Reply-To: Mailing List Sender: Mailing List From: "Balaji R (Networking) - CTD, Chennai." Subject: Re: Route Aggregation To: OSPF@DISCUSS.MICROSOFT.COM Eric, Yes, if the router lies in the routing path of the next hop router, loop will ensue. I was talking about a special case of this, where the sending router happens to be the next hop of the next hop router (but it does not really matter if it is or not :-)). Split horizon only takes care of looping during control information exchange. I was referring to data packet bouncing back and forth between the two. (In the case that wu pointed out, the routing table updates were already received and aggregated. We are only interested in what happens after the aggregation. Split horizon will only prevent this aggregated information from being sent back to the same router that originated it and not the data looping that occurs after aggregation. ). Eric - I did not understand how split horizon will create a black hole? Can you please explain? Thanks, Balaji.R. -----Original Message----- From: Eric Gray [mailto:eric.gray@SANDBURST.COM] Sent: Tuesday, April 23, 2002 8:03 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: Route Aggregation Balaji R (Networking) - CTD, Chennai. wrote: >-----Original Message----- >From: wu min [mailto:made_in__china@HOTMAIL.COM] >Sent: Tuesday, April 23, 2002 6:05 AM >To: OSPF@DISCUSS.MICROSOFT.COM >Subject: Route Aggregation > >Hi, > >I have some questions and I hope someone out there can help. > >1) I understand that when a router tries to route a packet it must use the >packet's destination address to search for the longest match prefix entry >in it routing table to determine how and where the packet is supposed to be >forwarded. Supposely the router break this rule and use a prefix which is >not the longest match regardless of the existent of a longer one, what would >be the consequences assuming that the next hop router for the chosen prefix >is different from the longest match prefix? Is this safe? > Not all the time. If the other router thinks that you are the next >hop for the longer prefix, this will result in a routing loop. > I doubt that this is ever 'safe' - though you may get away with it. In order to get away with it, other routers must not have a preferred route such that the packet will subsequently arrive at the same router. The case where the peer router thinks the local router is the next hop will not often result in a routing loop - it would be a black hole instead - because 'split- horizon' behavior will prevent it from returning the packet to the router from which it has received it. But there are a ton of other ways in which the packet may end up arriving at the local router again, resulting in a loop. > > >... > -- -- Eric Gray (mailto:eric.gray@sandburst.com) http://www.mindspring.com/~ewgray From owner-ospf@DISCUSS.MICROSOFT.COM Tue Apr 23 10:53:40 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20741 for ; Tue, 23 Apr 2002 10:53:40 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <9.FF43F2EE@PEAR.EASE.LSOFT.COM>; Tue, 23 Apr 2002 10:53:21 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 909107 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 23 Apr 2002 10:53:38 -0400 Received: from 64.4.37.120 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Tue, 23 Apr 2002 10:53:38 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 23 Apr 2002 07:53:37 -0700 Received: from 155.245.254.253 by pv2fd.pav2.hotmail.msn.com with HTTP; Tue, 23 Apr 2002 14:53:37 GMT X-Originating-IP: [155.245.254.253] Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 23 Apr 2002 14:53:37.0871 (UTC) FILETIME=[A66655F0:01C1EAD6] Message-ID: Date: Tue, 23 Apr 2002 14:53:37 +0000 Reply-To: Mailing List Sender: Mailing List From: wu min Subject: Re: Route Aggregation To: OSPF@DISCUSS.MICROSOFT.COM Hi again, Thank you Acee Lindem and Balaji for your informative comments. I have more questions. 1) What are the advantages and disadvatanges of route aggregation? 2) On what basis do we need to use route aggregation? 3) I believe route aggregation process will cause ambiguous link metric(s). How critical will this ambiguity cause? Further question below: >>Given that a router has the following fictious routing information: >> >>i) prefix = 10.2.153.178/32; next-hop = router2 >>ii) prefix = 10.2.153/23; next-hop = router2 >>iii) prefix = 10.2.154/23; next-hop = router2 >>iv) prefix = 10.2/16; next-hop = router2 >> >>The question is, is it possible to aggregate them such that we have >>only >>the following prefix in the routing table? >> >>iv) prefix = 10.2/16; next-hop = router2 >> >>Are you talking about External-LSA's here? If so, it is better not to >>aggregate as the intent of the sender might to update just the LSA >>that changes. (Otherwise, the sender would have probably aggregated >>the routes). If you aggregated, you wouldn't be able to do >>incremental routing table calculation. I am a newbie in OSPF, but I would appreciate a brief explanation about external-LSA. Does route aggregation process only allowable on external-LSA? Thank you in advance. -Tze Ven _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. From owner-ospf@DISCUSS.MICROSOFT.COM Tue Apr 23 13:29:03 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28527 for ; Tue, 23 Apr 2002 13:29:02 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <5.F3EA5B24@PEAR.EASE.LSOFT.COM>; Tue, 23 Apr 2002 13:28:45 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 910098 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 23 Apr 2002 13:29:02 -0400 Received: from 216.57.132.42 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Tue, 23 Apr 2002 13:29:01 -0400 MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3CC599DC.30003@sandburst.com> Date: Tue, 23 Apr 2002 13:29:00 -0400 Reply-To: Mailing List Sender: Mailing List From: Eric Gray Subject: Re: Route Aggregation To: OSPF@DISCUSS.MICROSOFT.COM Content-Transfer-Encoding: 7bit Balaji, Apologies for perhaps using the wrong term. The same concept that applies to control messages should apply to data. What conceivable advantage is there to sending a packet back to the same box it was received from, using the same (potentially virtual) interface as it was received on? If nothing has changed except for swapping the MAC addresses around, what reason does a box have for believing the other box will do otherwise than it did most recently? In some implementations, it is trivially easy to prevent this from happening. In such an implementation, packets would be dropped rather than forwarded in a loop. Thus an upstream router (WRT this route) would be sending packets to a peer that will simply drop them. This is one of the definitions for a black hole. As I understand it, routers treat packets received from their next hop with respect to the packet's destination as if the destination is unreachable. You wrote: >Eric, > >Yes, if the router lies in the routing path of the next hop router, loop >will ensue. I was talking about a special case of this, where the sending >router happens to be the next hop of the next hop router (but it does not >really matter if it is or not :-)). Split horizon only takes care of looping >during control information exchange. I was referring to data packet bouncing >back and forth between the two. (In the case that wu pointed out, the >routing table updates were already received and aggregated. We are only >interested in what happens after the aggregation. Split horizon will only >prevent this aggregated information from being sent back to the same router >that originated it and not the data looping that occurs after aggregation. >). > >Eric - I did not understand how split horizon will create a black hole? Can >you please explain? > >Thanks, >Balaji.R. > > >-----Original Message----- >From: Eric Gray [mailto:eric.gray@SANDBURST.COM] >Sent: Tuesday, April 23, 2002 8:03 PM >To: OSPF@DISCUSS.MICROSOFT.COM >Subject: Re: Route Aggregation > > >Balaji R (Networking) - CTD, Chennai. wrote: > >>-----Original Message----- >>From: wu min [mailto:made_in__china@HOTMAIL.COM] >>Sent: Tuesday, April 23, 2002 6:05 AM >>To: OSPF@DISCUSS.MICROSOFT.COM >>Subject: Route Aggregation >> >>Hi, >> >>I have some questions and I hope someone out there can help. >> >>1) I understand that when a router tries to route a packet it must use the >>packet's destination address to search for the longest match prefix entry >>in it routing table to determine how and where the packet is supposed to be >>forwarded. Supposely the router break this rule and use a prefix which is >>not the longest match regardless of the existent of a longer one, what >> >would > >>be the consequences assuming that the next hop router for the chosen prefix >>is different from the longest match prefix? Is this safe? >> Not all the time. If the other router thinks that you are the next >>hop for the longer prefix, this will result in a routing loop. >> >I doubt that this is ever 'safe' - though you may get away with it. > >In order to get away with it, other routers must not have a preferred route >such that the packet will subsequently arrive at the same router. The case >where the peer router thinks the local router is the next hop will not >often >result in a routing loop - it would be a black hole instead - because >'split- >horizon' behavior will prevent it from returning the packet to the router >from which it has received it. But there are a ton of other ways in which >the packet may end up arriving at the local router again, resulting in a >loop. > >> >>... >> > > >-- >-- >Eric Gray (mailto:eric.gray@sandburst.com) >http://www.mindspring.com/~ewgray > -- -- Eric Gray (mailto:eric.gray@sandburst.com) http://www.mindspring.com/~ewgray From owner-ospf@DISCUSS.MICROSOFT.COM Wed Apr 24 06:48:15 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29107 for ; Wed, 24 Apr 2002 06:48:15 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <13.FAC417EF@PEAR.EASE.LSOFT.COM>; Wed, 24 Apr 2002 6:47:52 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 913129 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 24 Apr 2002 06:48:09 -0400 Received: from 202.54.64.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Wed, 24 Apr 2002 06:48:08 -0400 Received: by GANESH with Internet Mail Service (5.5.2653.19) id ; Wed, 24 Apr 2002 16:25:40 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Wed, 24 Apr 2002 16:16:25 +0530 Reply-To: Mailing List Sender: Mailing List From: "Balaji R (Networking) - CTD, Chennai." Subject: Re: Route Aggregation To: OSPF@DISCUSS.MICROSOFT.COM Wu, That advantage of aggregation is that you consume less network bandwidth (during advertisements), less memory(for storing routes) and less CPU (during routing table calculation). However, this condensation of information could result in suboptimal routing. Summarization is performed on area boundaries (OSPF runs a link-state protocol within each area and a distance-vector protocol between areas. This makes the protocol more scalable.) and during redistribution from other routing protocols, like BGP. Such redistributed routes are advertised using External-LSAs. Thanks, Balaji.R. Hi again, Thank you Acee Lindem and Balaji for your informative comments. I have more questions. 1) What are the advantages and disadvatanges of route aggregation? 2) On what basis do we need to use route aggregation? 3) I believe route aggregation process will cause ambiguous link metric(s). How critical will this ambiguity cause? Further question below: >>Given that a router has the following fictious routing information: >> >>i) prefix = 10.2.153.178/32; next-hop = router2 >>ii) prefix = 10.2.153/23; next-hop = router2 >>iii) prefix = 10.2.154/23; next-hop = router2 >>iv) prefix = 10.2/16; next-hop = router2 >> >>The question is, is it possible to aggregate them such that we have >>only >>the following prefix in the routing table? >> >>iv) prefix = 10.2/16; next-hop = router2 >> >>Are you talking about External-LSA's here? If so, it is better not to >>aggregate as the intent of the sender might to update just the LSA >>that changes. (Otherwise, the sender would have probably aggregated >>the routes). If you aggregated, you wouldn't be able to do >>incremental routing table calculation. I am a newbie in OSPF, but I would appreciate a brief explanation about external-LSA. Does route aggregation process only allowable on external-LSA? Thank you in advance. -Tze Ven _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. From owner-ospf@DISCUSS.MICROSOFT.COM Wed Apr 24 08:14:17 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00997 for ; Wed, 24 Apr 2002 08:14:16 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <1.FEA935F5@PEAR.EASE.LSOFT.COM>; Wed, 24 Apr 2002 8:13:58 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 913399 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 24 Apr 2002 08:14:14 -0400 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Wed, 24 Apr 2002 08:04:14 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00652; Wed, 24 Apr 2002 08:04:12 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200204241204.IAA00652@ietf.org> Date: Wed, 24 Apr 2002 08:04:12 -0400 Reply-To: Mailing List Sender: Mailing List Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ash-manral-ospf-congestion-control-00.txt To: OSPF@DISCUSS.MICROSOFT.COM --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Congestion Avoidance & Control for OSPF Networks Author(s) : J. Ash et al. Filename : draft-ash-manral-ospf-congestion-control-00.txt Pages : Date : 23-Apr-02 Based on overload and failure experience with link-state protocols, this draft identifies means to enable link-state protocols to: o avoid getting into congestion states wherever possible o respond gracefully to network overloads and failures o gracefully recover from massive loss of topology database information The proposed mechanisms include the following: o throttle setups of link adjacencies o reduce the rate of flooding of link-state-advertisements(LSAs) o prioritized treatment of Hello & LSA ack packets o database backup & resynchronization for graceful recovery from loss of topology database information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ash-manral-ospf-congestion-control-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-ash-manral-ospf-congestion-control-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-ash-manral-ospf-congestion-control-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: <20020423121318.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ash-manral-ospf-congestion-control-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ash-manral-ospf-congestion-control-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020423121318.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@DISCUSS.MICROSOFT.COM Wed Apr 24 09:00:14 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02337 for ; Wed, 24 Apr 2002 09:00:09 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <9.FF43F362@PEAR.EASE.LSOFT.COM>; Wed, 24 Apr 2002 8:59:50 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 913461 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 24 Apr 2002 09:00:06 -0400 Received: from 192.25.42.26 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Wed, 24 Apr 2002 08:50:05 -0400 Received: from msgrel1.sgp.agilent.com (msgrel1.sgp.agilent.com [141.183.101.233]) by msgbas1.sgp.agilent.com (Postfix) with ESMTP id CDF164BE for ; Wed, 24 Apr 2002 20:50:05 +0800 (SGP) Received: from apbrg1.sgp.agilent.com (apbrg1.sgp.agilent.com [141.183.6.40]) by msgrel1.sgp.agilent.com (Postfix) with SMTP id E6FE2B66 for ; Wed, 24 Apr 2002 20:50:00 +0800 (SGP) Received: from 141.183.6.40 by apbrg1.sgp.agilent.com (InterScan E-Mail VirusWall NT); Wed, 24 Apr 2002 20:50:04 +0800 Received: by apbrg1.sgp.agilent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 24 Apr 2002 20:50:04 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Message-ID: <0333DB893597D311920D0090279AA8F009757446@apmail3.sgp.agilent.com> Date: Wed, 24 Apr 2002 20:50:03 +0800 Reply-To: Mailing List Sender: Mailing List From: "PLACID,JOSEPH (Non-A-India,ex1)" Subject: OSPF AREAS To: OSPF@DISCUSS.MICROSOFT.COM Sec 3, RFC 2328 says "A router actually has a seperate link-state database for each area it is connected to" But why is an area a defined to be a collection of links/interfaces.So a router with interfaces connected to multiple areas (lets say two) will have two seperate link state databases in its memory? Why can't an area be a collection of routers? What are the advantages/disadvantages? Joseph Placid From owner-ospf@DISCUSS.MICROSOFT.COM Wed Apr 24 09:49:53 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05640 for ; Wed, 24 Apr 2002 09:49:53 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <10.F8E03FF9@PEAR.EASE.LSOFT.COM>; Wed, 24 Apr 2002 9:49:28 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 913664 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 24 Apr 2002 09:49:46 -0400 Received: from 198.62.10.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Wed, 24 Apr 2002 09:49:46 -0400 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <2PDR20P9>; Wed, 24 Apr 2002 09:49:40 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Wed, 24 Apr 2002 09:49:13 -0400 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: I-D ACTION:draft-ash-manral-ospf-congestion-control-00.txt To: OSPF@DISCUSS.MICROSOFT.COM Hi Folks, A new draft which talks about failures that some providers have had with their LS protocols, due to congestion/overload and solutions to it for OSPF networks has been posted. We have been working on this draft for quite some time now and we discussed this with a lot of folks in Minneapolis at the last IETF. We have received a lot of feedback for the pre-published versions of this draft, for which we would like to thank Alex Zinin, Russ White, Dave Katz, Alvaro Retana and others. It would be nice to discuss any issues you may have with the draft and either mail Jerry or me regarding any queries, either on the list or personally. The link to the draft again is http://www.ietf.org/internet-drafts/draft-ash-manral-ospf-congestion-control -00.txt Thanks a lot, Vishwas -----Original Message----- From: Internet-Drafts@IETF.ORG [mailto:Internet-Drafts@IETF.ORG] Sent: Wednesday, April 24, 2002 5:34 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: I-D ACTION:draft-ash-manral-ospf-congestion-control-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Congestion Avoidance & Control for OSPF Networks Author(s) : J. Ash et al. Filename : draft-ash-manral-ospf-congestion-control-00.txt Pages : Date : 23-Apr-02 Based on overload and failure experience with link-state protocols, this draft identifies means to enable link-state protocols to: o avoid getting into congestion states wherever possible o respond gracefully to network overloads and failures o gracefully recover from massive loss of topology database information The proposed mechanisms include the following: o throttle setups of link adjacencies o reduce the rate of flooding of link-state-advertisements(LSAs) o prioritized treatment of Hello & LSA ack packets o database backup & resynchronization for graceful recovery from loss of topology database information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ash-manral-ospf-congestion-control -00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-ash-manral-ospf-congestion-control-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-ash-manral-ospf-congestion-control-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. From owner-ospf@DISCUSS.MICROSOFT.COM Wed Apr 24 12:38:17 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25576 for ; Wed, 24 Apr 2002 12:38:16 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <5.F3EA5B92@PEAR.EASE.LSOFT.COM>; Wed, 24 Apr 2002 12:37:58 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 914138 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 24 Apr 2002 12:38:16 -0400 Received: from 207.217.120.50 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Wed, 24 Apr 2002 12:38:16 -0400 Received: from user-2ivfn94.dialup.mindspring.com ([165.247.221.36] helo=earthlink.net) by avocet.prod.itd.earthlink.net with esmtp (Exim 3.33 #2) id 170PmU-0002Y7-00 for ospf@discuss.microsoft.com; Wed, 24 Apr 2002 09:38:14 -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 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3CC6E145.83D20EB2@earthlink.net> Date: Wed, 24 Apr 2002 09:45:57 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: OSPF rfc 2328 :Must:Should : Inactivity timer To: OSPF@DISCUSS.MICROSOFT.COM Content-Transfer-Encoding: 7bit Group I am looking for a consensus on how literally, the OSPF standardized RFCs need to be followed. In standard RFC language there is a section that says the requirement to follow certain sections or subsections of a RFC. This section uses words such as "May", "Should", "Must", etc. This older doc doesn't follow that type of language. With implimentations of my past there was a architecture design doc and at least a implimentation doc. The implimentation could differ from the architecture design, but still impliment like functionality. I associate the RFCs as more of a arch doc and that implimentations can vary as long as they impliment like functionality and have a like external behaviour. So, I have had a few converstations with various people not in this discussion group and would like to get a consensus. For instance ... in the rfc2328, section 10 Neighbor Data struct, their is a specified item as Inactivity timer. This forces a single timer per neighbor per this functionality. I propose that it should be sensible that if there are alternate solutions. Assuming that their are a number of neighbors per interface, it would be a simple matter to place all hello protocol speaking neighbors on this interface together within say a link list and be able to walk the list. A single periodic timer would be created for all neighbors on this list that would decrement the interface hello interval time. If a hello is recieved before multiple hello intervals time, then the value is reset to the interface RouterDeadInterval secs. The assumption here is that I prefer to do a lookup, and neighbor walking once per hello interval vs repeated timer creations, timer cancels per neighbor, etc. The end result is the same, if you don't see a hello from a neighbor within the timeframe, you are going to do the same work as if the single neighbor Inactivity timer fired. So, am I wrong here where each item MUST be followed to a strict same implimentation stardard? And SHOULD there be clauses within such docs that these items are SHOULDs and not MUSTs? Mitchell Erblich From owner-ospf@DISCUSS.MICROSOFT.COM Wed Apr 24 15:24:39 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04314 for ; Wed, 24 Apr 2002 15:24:38 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <9.FF43F388@PEAR.EASE.LSOFT.COM>; Wed, 24 Apr 2002 15:24:21 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 914848 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 24 Apr 2002 15:24:39 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Wed, 24 Apr 2002 15:24:39 -0400 Received: from redback.com (login003.redback.com [155.53.12.55]) by prattle.redback.com (Postfix) with ESMTP id EA8BC262810 for ; Wed, 24 Apr 2002 12:24:37 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020205 X-Accept-Language: en-us MIME-Version: 1.0 References: <0333DB893597D311920D0090279AA8F009757446@apmail3.sgp.agilent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3CC705B3.4080208@redback.com> Date: Wed, 24 Apr 2002 15:21:23 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: OSPF AREAS To: OSPF@DISCUSS.MICROSOFT.COM Content-Transfer-Encoding: 7bit Joseph, PLACID,JOSEPH (Non-A-India,ex1) wrote: > Sec 3, RFC 2328 says "A router actually has a seperate link-state database > for each area it is connected to" > But why is an area a defined to be a collection of links/interfaces.So a > router with interfaces connected to multiple areas (lets say two) will have > two seperate link state databases in its memory? There is one database for the topology for each area. Areas are required to provide a level of hierarchy. A separate SPF calculation is run for each area. One can always use a single area if desired. > Why can't an area be a collection of routers? This is simply terminolgy. In the SPF algorithm, routers and multi-access networks are graph verticies and links are their edges. > What are the advantages/disadvantages? > > > Joseph Placid > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Wed Apr 24 15:45:44 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05171 for ; Wed, 24 Apr 2002 15:45:42 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <11.F9E55F64@PEAR.EASE.LSOFT.COM>; Wed, 24 Apr 2002 15:45:25 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 914898 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 24 Apr 2002 15:45:43 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Wed, 24 Apr 2002 15:45:43 -0400 Received: from redback.com (login003.redback.com [155.53.12.55]) by prattle.redback.com (Postfix) with ESMTP id 35499CAB63 for ; Wed, 24 Apr 2002 12:45:42 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020205 X-Accept-Language: en-us MIME-Version: 1.0 References: <3CC6E145.83D20EB2@earthlink.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3CC70AA3.7090401@redback.com> Date: Wed, 24 Apr 2002 15:42:27 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: OSPF rfc 2328 :Must:Should : Inactivity timer To: OSPF@DISCUSS.MICROSOFT.COM Content-Transfer-Encoding: 7bit Mitchell, It would be an understatement to say I don't think this is a good idea. First, if I understand your algorithm correctly (which I may not), you'll be off by an average of 1/2 the hello interval. Second, this scheme will encourage synchronization of neighbor events. If timers are expensive in your implementation, you can still do it with a single timer (of granularity 1 second) or a timer that you keep resetting to the minimum neighbor inactivity expiration time. Thanks, Acee Erblichs wrote: > Group I am looking for a consensus on how literally, the OSPF > standardized RFCs need to be followed. > > In standard RFC language there is a section that says the > requirement to follow certain sections or subsections of > a RFC. This section uses words such as "May", "Should", "Must", > etc. This older doc doesn't follow that type of language. > > With implimentations of my past there was a architecture > design doc and at least a implimentation doc. The implimentation > could differ from the architecture design, but still impliment > like functionality. I associate the RFCs as more of a arch > doc and that implimentations can vary as long as they > impliment like functionality and have a like external behaviour. > > So, I have had a few converstations with various people > not in this discussion group and would like to get a consensus. > > For instance ... > > in the rfc2328, section 10 Neighbor Data struct, > their is a specified item as Inactivity timer. This forces > a single timer per neighbor per this functionality. I propose > that it should be sensible that if there are alternate > solutions. Assuming that their are a number of neighbors per > interface, it would be a simple matter to place all hello > protocol speaking neighbors on this interface together within > say a link list and be able to walk the list. A single periodic > timer would be created for all neighbors on this list that would > decrement the interface hello interval time. If a hello is > recieved before multiple hello intervals time, then the value > is reset to the interface RouterDeadInterval secs. The assumption > here is that I prefer to do a lookup, and neighbor walking once > per hello interval vs repeated timer creations, timer cancels per > neighbor, etc. > > The end result is the same, if you don't see a hello from > a neighbor within the timeframe, you are going to do the > same work as if the single neighbor Inactivity timer fired. > > So, am I wrong here where each item MUST be followed to > a strict same implimentation stardard? And SHOULD there be > clauses within such docs that these items are SHOULDs and > not MUSTs? > > Mitchell Erblich > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Wed Apr 24 19:36:46 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11753 for ; Wed, 24 Apr 2002 19:36:45 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <1.FEA93637@PEAR.EASE.LSOFT.COM>; Wed, 24 Apr 2002 19:36:26 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 915619 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 24 Apr 2002 19:36:44 -0400 Received: from 207.217.120.49 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Wed, 24 Apr 2002 19:36:44 -0400 Received: from user-2ivfmnd.dialup.mindspring.com ([165.247.218.237] helo=earthlink.net) by scaup.prod.itd.earthlink.net with esmtp (Exim 3.33 #2) id 170WJW-0007ks-00 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 24 Apr 2002 16:36:43 -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: <3CC6E145.83D20EB2@earthlink.net> <3CC70AA3.7090401@redback.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3CC7435F.6128E9CB@earthlink.net> Date: Wed, 24 Apr 2002 16:44:31 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: OSPF rfc 2328 :Must:Should : Inactivity timer To: OSPF@DISCUSS.MICROSOFT.COM Content-Transfer-Encoding: 7bit I am only talking about local reception of the processing of hellos and the ability to cancel the local procedure that would be called if there was no hellos seen in deadrouter time. No statement on the local xmit'ion of hellos is made. For the sake of agreement, the granularity could be 1 sec, 1/2 sec of walking the rcv hello protocol neighbor list. But all that depends on the setting of hellointerval for the interface. If the hellointerval was 10 secs, walking it every 2 sec or 3 secs may not be a issue. It could be a CLI setting per interface. Let me re-state this to the unlikely extreme simple case.... Assume that there are 1000 routers on the same interface using the hello protocol of 3 secs hellointerval and 9 secs for deadrouter time. ---And yes hello rcv events would tend to be synchronized per 3 secs. But this is only for routers going away. And don't we want to have our routers databases synchronized. At every 3 sec mark in this example I would inform every adj router (via my hellos) that I lost at least 2-way state with a set of routers. This would mean that on the avg every like interface would experience the pairing of 333 cancel timer calls and 333 create_timer calls every sec. Just for this specified functionality... Doesn't this seem to be abit non-scalable? Alot of un-neccessary overhead? By starting with my simplistic suggestion, their would be 1 timer firing every 3 secs, decrementing a initial 9 secs value per neighbor on this list. Only if a hello has not been seen for at least 3 looping values, will it be processed with the set of deadrouter timer procedures. Which comes back to the original two questions? Basicly is the per neighbor deadinterval timer functionality a requirement (a MUST)? Mitchell Erblich ======================= Acee Lindem wrote: > > Mitchell, > > It would be an understatement to say I don't think this is > a good idea. First, if I understand your algorithm correctly (which > I may not), you'll be off by an average of 1/2 the hello interval. > Second, this scheme will encourage synchronization of neighbor > events. > > If timers are expensive in your implementation, you can still do it with a > single timer (of granularity 1 second) or a timer that you keep resetting > to the minimum neighbor inactivity expiration time. > > Thanks, > Acee > > Erblichs wrote: > > Group I am looking for a consensus on how literally, the OSPF > > standardized RFCs need to be followed. > > > > In standard RFC language there is a section that says the > > requirement to follow certain sections or subsections of > > a RFC. This section uses words such as "May", "Should", "Must", > > etc. This older doc doesn't follow that type of language. > > > > With implimentations of my past there was a architecture > > design doc and at least a implimentation doc. The implimentation > > could differ from the architecture design, but still impliment > > like functionality. I associate the RFCs as more of a arch > > doc and that implimentations can vary as long as they > > impliment like functionality and have a like external behaviour. > > > > So, I have had a few converstations with various people > > not in this discussion group and would like to get a consensus. > > > > For instance ... > > > > in the rfc2328, section 10 Neighbor Data struct, > > their is a specified item as Inactivity timer. This forces > > a single timer per neighbor per this functionality. I propose > > that it should be sensible that if there are alternate > > solutions. Assuming that their are a number of neighbors per > > interface, it would be a simple matter to place all hello > > protocol speaking neighbors on this interface together within > > say a link list and be able to walk the list. A single periodic > > timer would be created for all neighbors on this list that would > > decrement the interface hello interval time. If a hello is > > recieved before multiple hello intervals time, then the value > > is reset to the interface RouterDeadInterval secs. The assumption > > here is that I prefer to do a lookup, and neighbor walking once > > per hello interval vs repeated timer creations, timer cancels per > > neighbor, etc. > > > > The end result is the same, if you don't see a hello from > > a neighbor within the timeframe, you are going to do the > > same work as if the single neighbor Inactivity timer fired. > > > > So, am I wrong here where each item MUST be followed to > > a strict same implimentation stardard? And SHOULD there be > > clauses within such docs that these items are SHOULDs and > > not MUSTs? > > > > Mitchell Erblich > > > > > > -- > Acee From owner-ospf@DISCUSS.MICROSOFT.COM Thu Apr 25 10:39:11 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07587 for ; Thu, 25 Apr 2002 10:39:11 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <13.FAC41886@PEAR.EASE.LSOFT.COM>; Thu, 25 Apr 2002 10:38:47 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 918553 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 25 Apr 2002 10:39:06 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Thu, 25 Apr 2002 10:39:06 -0400 Received: from redback.com (login001.redback.com [155.53.12.18]) by prattle.redback.com (Postfix) with ESMTP id C21E34BA21F for ; Thu, 25 Apr 2002 07:39:04 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020205 X-Accept-Language: en-us MIME-Version: 1.0 References: <3CC6E145.83D20EB2@earthlink.net> <3CC70AA3.7090401@redback.com> <3CC7435F.6128E9CB@earthlink.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3CC8143B.7060603@redback.com> Date: Thu, 25 Apr 2002 10:35:39 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: OSPF rfc 2328 :Must:Should : Inactivity timer To: OSPF@DISCUSS.MICROSOFT.COM Content-Transfer-Encoding: 7bit Erblichs, In your original E-mail I thought you implied the timer granularity for checking for inactive routers would be the hello interval. I agree that with a timer granularity of 1 second you can provide the same external behavior as a single inactivity timer per neighbor. Thanks, Acee Erblichs wrote: > I am only talking about local reception of the processing > of hellos and the ability to cancel the local procedure > that would be called if there was no hellos seen > in deadrouter time. No statement on the local xmit'ion > of hellos is made. > > For the sake of agreement, the granularity could > be 1 sec, 1/2 sec of walking the rcv hello protocol > neighbor list. But all that depends on the > setting of hellointerval for the interface. If > the hellointerval was 10 secs, walking it every > 2 sec or 3 secs may not be a issue. It could > be a CLI setting per interface. > > Let me re-state this to the unlikely extreme > simple case.... > Assume that there are 1000 routers on the same > interface using the hello protocol of 3 secs > hellointerval and 9 secs for deadrouter time. > ---And yes hello rcv events would tend to be > synchronized per 3 secs. But this is only for routers > going away. And don't we want to have our routers > databases synchronized. At every 3 sec mark in this > example I would inform every adj router (via my hellos) > that I lost at least 2-way state with a set of routers. > > This would mean that on the avg every like interface > would experience the pairing of 333 cancel timer calls > and 333 create_timer calls every sec. Just for this > specified functionality... > > Doesn't this seem to be abit non-scalable? Alot > of un-neccessary overhead? > > By starting with my simplistic suggestion, their would > be 1 timer firing every 3 secs, decrementing a initial > 9 secs value per neighbor on this list. Only if a hello > has not been seen for at least 3 looping values, will > it be processed with the set of deadrouter timer > procedures. > > Which comes back to the original two questions? Basicly > is the per neighbor deadinterval timer functionality > a requirement (a MUST)? > > Mitchell Erblich > ======================= > > Acee Lindem wrote: > >>Mitchell, >> >>It would be an understatement to say I don't think this is >>a good idea. First, if I understand your algorithm correctly (which >>I may not), you'll be off by an average of 1/2 the hello interval. >>Second, this scheme will encourage synchronization of neighbor >>events. >> >>If timers are expensive in your implementation, you can still do it with a >>single timer (of granularity 1 second) or a timer that you keep resetting >>to the minimum neighbor inactivity expiration time. >> >>Thanks, >>Acee >> >>Erblichs wrote: >> >>>Group I am looking for a consensus on how literally, the OSPF >>>standardized RFCs need to be followed. >>> >>>In standard RFC language there is a section that says the >>>requirement to follow certain sections or subsections of >>>a RFC. This section uses words such as "May", "Should", "Must", >>>etc. This older doc doesn't follow that type of language. >>> >>>With implimentations of my past there was a architecture >>>design doc and at least a implimentation doc. The implimentation >>>could differ from the architecture design, but still impliment >>>like functionality. I associate the RFCs as more of a arch >>>doc and that implimentations can vary as long as they >>>impliment like functionality and have a like external behaviour. >>> >>>So, I have had a few converstations with various people >>>not in this discussion group and would like to get a consensus. >>> >>>For instance ... >>> >>>in the rfc2328, section 10 Neighbor Data struct, >>>their is a specified item as Inactivity timer. This forces >>>a single timer per neighbor per this functionality. I propose >>>that it should be sensible that if there are alternate >>>solutions. Assuming that their are a number of neighbors per >>>interface, it would be a simple matter to place all hello >>>protocol speaking neighbors on this interface together within >>>say a link list and be able to walk the list. A single periodic >>>timer would be created for all neighbors on this list that would >>>decrement the interface hello interval time. If a hello is >>>recieved before multiple hello intervals time, then the value >>>is reset to the interface RouterDeadInterval secs. The assumption >>>here is that I prefer to do a lookup, and neighbor walking once >>>per hello interval vs repeated timer creations, timer cancels per >>>neighbor, etc. >>> >>>The end result is the same, if you don't see a hello from >>>a neighbor within the timeframe, you are going to do the >>>same work as if the single neighbor Inactivity timer fired. >>> >>>So, am I wrong here where each item MUST be followed to >>>a strict same implimentation stardard? And SHOULD there be >>>clauses within such docs that these items are SHOULDs and >>>not MUSTs? >>> >>>Mitchell Erblich >>> >>> >>> >>-- >>Acee >> > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Thu Apr 25 14:26:16 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01053 for ; Thu, 25 Apr 2002 14:26:15 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <15.F6DC6E52@PEAR.EASE.LSOFT.COM>; Thu, 25 Apr 2002 14:25:56 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 919321 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 25 Apr 2002 14:26:15 -0400 Received: from 207.217.120.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Thu, 25 Apr 2002 14:26:15 -0400 Received: from user-38lc0ks.dialup.mindspring.com ([209.86.2.156] helo=earthlink.net) by snipe.prod.itd.earthlink.net with esmtp (Exim 3.33 #2) id 170nwc-0005be-00 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 25 Apr 2002 11:26:14 -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: <0333DB893597D311920D0090279AA8F009757446@apmail3.sgp.agilent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3CC84C20.D051AAD6@earthlink.net> Date: Thu, 25 Apr 2002 11:34:08 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: OSPF AREAS To: OSPF@DISCUSS.MICROSOFT.COM Content-Transfer-Encoding: 7bit Joeseph, If I understand your question I would suggest you look at the general docs that you can find for the Link state protocol (IS-IS: Intermediate System - Intermediate System : aka router-router). The L1/L2 ISIS router resides completely within one area where the ABR (area border router sits) on the edges of two areas) as a comparison. BTW, all ISIS routers sit within a specific area. The OSPF and ISIS Link state routing protocols are very similar and still have enough differences to be interesting. In my opinion. Mitchell Erblich --------------------------- "PLACID,JOSEPH (Non-A-India,ex1)" wrote: > > Sec 3, RFC 2328 says "A router actually has a seperate link-state database > for each area it is connected to" > But why is an area a defined to be a collection of links/interfaces.So a > router with interfaces connected to multiple areas (lets say two) will have > two seperate link state databases in its memory? Why can't an area be a > collection of routers? What are the advantages/disadvantages? > > Joseph Placid From owner-ospf@DISCUSS.MICROSOFT.COM Thu Apr 25 15:06:49 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02265 for ; Thu, 25 Apr 2002 15:06:48 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <2.FF1FAF7B@PEAR.EASE.LSOFT.COM>; Thu, 25 Apr 2002 15:06:30 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 919407 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 25 Apr 2002 15:06:49 -0400 Received: from 207.217.120.49 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Thu, 25 Apr 2002 15:06:49 -0400 Received: from user-38lc0ks.dialup.mindspring.com ([209.86.2.156] helo=earthlink.net) by scaup.prod.itd.earthlink.net with esmtp (Exim 3.33 #2) id 170oZs-0002DA-00 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 25 Apr 2002 12:06:48 -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: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3CC855A2.ED5F88D3@earthlink.net> Date: Thu, 25 Apr 2002 12:14:42 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: draft..ospf-congestion-control-00.txt : 4.1.1 To: OSPF@DISCUSS.MICROSOFT.COM Content-Transfer-Encoding: 7bit My comment on section 4.1.1 1) "router goes down and comes back up again" A) If the new state of the neighbor is "down", then the RFC specifies to discard the resources associated with the neighbor. A new possible state of "zombie" (inherited from the UNIX OS) could keep some information from this now dead neighbor could be used to identify that this neighbor went down or is possibly unstable. Yes, additional CLI configuration commands and a timer would then be necessary to free the zombie neighbors after they have been down for x period of time. You could also do some special processing of router neighbors that return from the zombie state. B) If the new state is lesser than the oldstate, then new fields would be necessary to identify whether the oldstate was FULL or 2-WAY.. And again todo the necessary work in the future. It is possible to then only mark some type of work and being delayed until some time in the future (assuming that the 2-way or full will return in just a short period of time). MAX_ADJ_BUILD_COUNT 1) My suggestion is to use a time field here to identify if and when this value was reached and how long it is relevent. This time field will determine whether this just a burst (transient) of new adjs (2-way or full ) or a sustained problem. 2) Low Watermark value: With most threshold values, it is sensible to impliment a low-watermark type value that may be derived from the high-watermark value. This could be imlimented here by waiting for the MAX_ADJ_BUILD_CNT to drop to the low-watermark value before allowing new building of adjs back to the high watermark value. Then if the transition moves from high to low and back to high, the router would then know that there is still a sustained amount of work involved to finish building all the adjs. nit within 4.1.2 right now-- [RFC2474] :::: I don't see it listed in the section 8 referenes.. Mitchell Erblich From owner-ospf@DISCUSS.MICROSOFT.COM Fri Apr 26 08:24:28 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01060 for ; Fri, 26 Apr 2002 08:24:27 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <10.F8E040E8@PEAR.EASE.LSOFT.COM>; Fri, 26 Apr 2002 8:24:08 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 921884 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 26 Apr 2002 08:24:25 -0400 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Fri, 26 Apr 2002 08:14:25 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00680; Fri, 26 Apr 2002 08:14:23 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200204261214.IAA00680@ietf.org> Date: Fri, 26 Apr 2002 08:14:23 -0400 Reply-To: Mailing List Sender: Mailing List Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ospf-scalability-01.txt To: OSPF@DISCUSS.MICROSOFT.COM --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF. Title : Explicit Marking and Prioritized Treatment of Specific IGP Packets for Faster IGP Convergence and Improved Network Scalability and Stability Author(s) : G. Choudhury, V. Sapozhnikova Filename : draft-ietf-ospf-scalability-01.txt Pages : Date : 25-Apr-02 In this draft we propose the following mechanisms in order to allow fast IGP convergence and at the same time maintain scalability and stability of a network: (1) Explicitly mark Hello packets, to differentiate them from other IGP packets, so that efficient implementations can detect and process the Hello packets in a priority fashion. (2) In the absence of special marking, or in addition to it, use other mechanisms in order not to miss Hello packets. One example is to treat any packet received over a link as a surrogate for a Hello packet for the purpose of keeping the link alive. (3) The same type of explicit marking and prioritized treatment may be beneficial to other IGP packets as well. Some examples include (a) LSA acknowledgment packet, (b) Database description (DBD) packet from a slave that is used as an acknowledgement, and (c) LSAs carrying intra-area topology change information. It is possible that some implementations are already using one or more of the above mechanisms in order not to miss the processing of critical packets during periods of congestion. However, we suggest the above mechanisms to be included as part of the standard so that all implementations can benefit from them. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-scalability-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ospf-scalability-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ospf-scalability-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020425133940.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ospf-scalability-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ospf-scalability-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020425133940.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@DISCUSS.MICROSOFT.COM Fri Apr 26 08:26:20 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01152 for ; Fri, 26 Apr 2002 08:26:19 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <2.FF1FAFCA@PEAR.EASE.LSOFT.COM>; Fri, 26 Apr 2002 8:25:59 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 921933 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 26 Apr 2002 08:26:17 -0400 Received: from 198.62.10.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Fri, 26 Apr 2002 08:26:17 -0400 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <2PDRJD23>; Fri, 26 Apr 2002 08:26:12 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Fri, 26 Apr 2002 08:11:41 -0400 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: draft..ospf-congestion-control-00.txt : 4.1.1 To: OSPF@DISCUSS.MICROSOFT.COM Hi Mitchell, Thanks a lot for the comments. My comments are inline prefixed with a "VM>". Thanks, Vishwas -----Original Message----- From: Erblichs [mailto:erblichs@EARTHLINK.NET] Sent: Friday, April 26, 2002 12:45 AM To: OSPF@DISCUSS.MICROSOFT.COM Subject: draft..ospf-congestion-control-00.txt : 4.1.1 My comment on section 4.1.1 1) "router goes down and comes back up again" A) If the new state of the neighbor is "down", then the RFC specifies to discard the resources associated with the neighbor. A new possible state of "zombie" (inherited from the UNIX OS) could keep some information from this now dead neighbor could be used to identify that this neighbor went down or is possibly unstable. Yes, additional CLI configuration commands and a timer would then be necessary to free the zombie neighbors after they have been down for x period of time. You could also do some special processing of router neighbors that return from the zombie state. VM> The section generally talks about throttling setup of adjacencies, so the talk may not be absolutely relevent here. However not continuously allocing neighbour resources and freeing certainly helps in case we know the link/neighbor is flapping, we could however instead try to curtail effects neighbor flaps/link flaps at a lower layer itself. I however know some implementations, that keep the neighbors for some time before deleting them. By the way is the reference to discard neighbor resources RFC2328. Could you point me to the section this information is there? B) If the new state is lesser than the oldstate, then new fields would be necessary to identify whether the oldstate was FULL or 2-WAY.. And again todo the necessary work in the future. It is possible to then only mark some type of work and being delayed until some time in the future (assuming that the 2-way or full will return in just a short period of time). MAX_ADJ_BUILD_COUNT 1) My suggestion is to use a time field here to identify if and when this value was reached and how long it is relevent. This time field will determine whether this just a burst (transient) of new adjs (2-way or full ) or a sustained problem. VM> Yes, we can do that, however we have tried to get maximum mileage by doing the minimum.;-) 2) Low Watermark value: With most threshold values, it is sensible to impliment a low-watermark type value that may be derived from the high-watermark value. This could be imlimented here by waiting for the MAX_ADJ_BUILD_CNT to drop to the low-watermark value before allowing new building of adjs back to the high watermark value. Then if the transition moves from high to low and back to high, the router would then know that there is still a sustained amount of work involved to finish building all the adjs. VM> This sounds like a good idea. I will study the idea further and add it to the draft. nit within 4.1.2 right now-- [RFC2474] :::: I don't see it listed in the section 8 referenes.. VM> We will add it as reference. Thanks again. From owner-ospf@DISCUSS.MICROSOFT.COM Fri Apr 26 09:44:37 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04083 for ; Fri, 26 Apr 2002 09:44:36 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <11.F9E56036@PEAR.EASE.LSOFT.COM>; Fri, 26 Apr 2002 9:44:17 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 922093 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 26 Apr 2002 09:44:36 -0400 Received: from 209.119.0.19 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Fri, 26 Apr 2002 09:34:36 -0400 Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <5.F3EA5C79@PEAR.EASE.LSOFT.COM>; Fri, 26 Apr 2002 9:34:16 -0400 Message-ID: Date: Fri, 26 Apr 2002 09:34:36 -0400 Reply-To: Mailing List Sender: Mailing List From: Markus Prison Subject: Hide a network between two routers To: OSPF@DISCUSS.MICROSOFT.COM Hi people, my question will be if it's possible to hide a network between two routers for the routers that are connected to them within the ospf standard. When it's not possible what do you suggest what changes i must do in my ospf code of the two routers. From owner-ospf@DISCUSS.MICROSOFT.COM Fri Apr 26 09:58:14 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04522 for ; Fri, 26 Apr 2002 09:58:13 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <5.F3EA5C7A@PEAR.EASE.LSOFT.COM>; Fri, 26 Apr 2002 9:57:54 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 922133 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 26 Apr 2002 09:58:14 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Fri, 26 Apr 2002 09:58:13 -0400 Received: from redback.com (login002.redback.com [155.53.12.54]) by prattle.redback.com (Postfix) with ESMTP id 7DF9E1DCC7A for ; Fri, 26 Apr 2002 06:58:12 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020205 X-Accept-Language: en-us MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3CC95C1A.80003@redback.com> Date: Fri, 26 Apr 2002 09:54:34 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Hide a network between two routers To: OSPF@DISCUSS.MICROSOFT.COM Content-Transfer-Encoding: 7bit Markus Prison wrote: > Hi people, > > my question will be if it's possible to hide a network between two routers > for the routers that are connected to them within the ospf standard. What do you mean by hide - is it a single network? The simple answer would be to configure a tunnel between the two routers and run OSPF over the tunnel rather than the physical network you are trying to hide. > > When it's not possible what do you suggest what changes i must do in my > ospf code of the two routers. > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Fri Apr 26 10:09:18 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04949 for ; Fri, 26 Apr 2002 10:09:17 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <7.FEBE506A@PEAR.EASE.LSOFT.COM>; Fri, 26 Apr 2002 10:08:58 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 922178 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 26 Apr 2002 10:09:18 -0400 Received: from 192.67.198.70 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Fri, 26 Apr 2002 10:09:18 -0400 Received: from mprison ([212.18.200.6]) by post.webmailer.de (8.9.3/8.8.7) with SMTP id QAA24279 for ; Fri, 26 Apr 2002 16:09:16 +0200 (MEST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Message-ID: Date: Fri, 26 Apr 2002 16:11:01 +0200 Reply-To: Mailing List Sender: Mailing List From: Markus Prison Subject: AW: Hide a network between two routers To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3CC95C1A.80003@redback.com> Content-Transfer-Encoding: 7bit Hi Acee, it will be a single broadcast network betweeen this two routers. For ther routers around them it should look that there is no network between them. What do you meen with tunnel? Markus -----Ursprungliche Nachricht----- Von: Mailing List [mailto:OSPF@DISCUSS.MICROSOFT.COM]Im Auftrag von Acee Lindem Gesendet: Freitag, 26. April 2002 15:55 An: OSPF@DISCUSS.MICROSOFT.COM Betreff: Re: Hide a network between two routers Markus Prison wrote: > Hi people, > > my question will be if it's possible to hide a network between two routers > for the routers that are connected to them within the ospf standard. What do you mean by hide - is it a single network? The simple answer would be to configure a tunnel between the two routers and run OSPF over the tunnel rather than the physical network you are trying to hide. > > When it's not possible what do you suggest what changes i must do in my > ospf code of the two routers. > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Fri Apr 26 10:23:46 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05481 for ; Fri, 26 Apr 2002 10:23:44 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <4.F02EEDD5@PEAR.EASE.LSOFT.COM>; Fri, 26 Apr 2002 10:23:26 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 922238 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 26 Apr 2002 10:23:46 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Fri, 26 Apr 2002 10:23:45 -0400 Received: from redback.com (login002.redback.com [155.53.12.54]) by prattle.redback.com (Postfix) with ESMTP id 4D7A41531C5 for ; Fri, 26 Apr 2002 07:23:44 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020205 X-Accept-Language: en-us MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3CC96216.2070706@redback.com> Date: Fri, 26 Apr 2002 10:20:06 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: AW: Hide a network between two routers To: OSPF@DISCUSS.MICROSOFT.COM Content-Transfer-Encoding: 7bit Markus Prison wrote: > Hi Acee, > > it will be a single broadcast network betweeen this two routers. > For ther routers around them it should look that there is no network between > them. > > What do you meen with tunnel? I mean a GRE or IPIP tunnel. You can do it with OSPF but it is ugly. 1. Configure the "hidden" network in a separate area. 2. Configure "no-advertise" ranges for the "hidden" network. 3. Configure a virtual link between the two routers traversing the separate area. > > Markus > > -----Ursprungliche Nachricht----- > Von: Mailing List [mailto:OSPF@DISCUSS.MICROSOFT.COM]Im Auftrag von Acee > Lindem > Gesendet: Freitag, 26. April 2002 15:55 > An: OSPF@DISCUSS.MICROSOFT.COM > Betreff: Re: Hide a network between two routers > > > Markus Prison wrote: > >>Hi people, >> >>my question will be if it's possible to hide a network between two routers >>for the routers that are connected to them within the ospf standard. >> > > What do you mean by hide - is it a single network? The simple answer would > be to configure a tunnel between the two routers and run OSPF over the > tunnel rather than the physical network you are trying to hide. > > >>When it's not possible what do you suggest what changes i must do in my >>ospf code of the two routers. >> >> >> > > > -- > Acee > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Fri Apr 26 12:51:24 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10445 for ; Fri, 26 Apr 2002 12:51:24 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <1.FEA936FF@PEAR.EASE.LSOFT.COM>; Fri, 26 Apr 2002 12:51:04 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 922627 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 26 Apr 2002 12:51:24 -0400 Received: from 207.217.120.120 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Fri, 26 Apr 2002 12:51:24 -0400 Received: from user-2ivfi6p.dialup.mindspring.com ([165.247.200.217] helo=earthlink.net) by albatross.prod.itd.earthlink.net with esmtp (Exim 3.33 #2) id 1718wM-0003in-00 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 26 Apr 2002 09:51:23 -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: <3CC855A2.ED5F88D3@earthlink.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3CC98766.2D9F31B@earthlink.net> Date: Fri, 26 Apr 2002 09:59:18 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: draft..-congest-control-00.txt : New sect To: OSPF@DISCUSS.MICROSOFT.COM Content-Transfer-Encoding: 7bit Suggestion for a new section... Sorry, I have done alot of work with congestion and scaling... With the assumption of heterogeneous devices that support different levels of support for congestion, I would to add something like the following for the legacy devices. With the knowledge of sustained local congestion, some processes may have delayed processing of such items as the Link State database (See the 4.2.2.4 section). Thus, to support the legacy devices it is suggested that some flooding of originated LSAs with excessively high link cost metrics be done. This value should be set to LSInfinity or a close approximate value. This should minimize the use of this congested router as a transit router while under congestion... When congestion subsides the LSAs may be re-flooded with the appropriate costs of this non-congested link. Mitchell Erblich From owner-ospf@DISCUSS.MICROSOFT.COM Fri Apr 26 14:27:45 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21935 for ; Fri, 26 Apr 2002 14:27:44 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <3.F8156157@PEAR.EASE.LSOFT.COM>; Fri, 26 Apr 2002 14:27:24 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 922968 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 26 Apr 2002 14:27:44 -0400 Received: from 198.62.10.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Fri, 26 Apr 2002 14:27:44 -0400 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <2PDRJ1A5>; Fri, 26 Apr 2002 14:27:37 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Fri, 26 Apr 2002 14:27:26 -0400 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: draft..-congest-control-00.txt : New sect To: OSPF@DISCUSS.MICROSOFT.COM Mitchell, Thanks for the nice idea you have given. A thing similar to what you have said exists in OSPF, check RFC3137 - OSPF Stub Router Advertisement. The idea however does not help much in the case of congestion caused by control protocols traffic, as the flooding still takes place normally, though the data traffic may be reduced. We are trying to focus more on reducing control traffic here. Thanks, Vishwas -----Original Message----- From: Erblichs [mailto:erblichs@EARTHLINK.NET] Sent: Friday, April 26, 2002 10:29 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: draft..-congest-control-00.txt : New sect Suggestion for a new section... Sorry, I have done alot of work with congestion and scaling... With the assumption of heterogeneous devices that support different levels of support for congestion, I would to add something like the following for the legacy devices. With the knowledge of sustained local congestion, some processes may have delayed processing of such items as the Link State database (See the 4.2.2.4 section). Thus, to support the legacy devices it is suggested that some flooding of originated LSAs with excessively high link cost metrics be done. This value should be set to LSInfinity or a close approximate value. This should minimize the use of this congested router as a transit router while under congestion... When congestion subsides the LSAs may be re-flooded with the appropriate costs of this non-congested link. Mitchell Erblich From owner-ospf@DISCUSS.MICROSOFT.COM Fri Apr 26 16:00:19 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03423 for ; Fri, 26 Apr 2002 16:00:19 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <15.F6DC6EC6@PEAR.EASE.LSOFT.COM>; Fri, 26 Apr 2002 15:59:50 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 923208 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 26 Apr 2002 16:00:10 -0400 Received: from 66.7.144.30 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Fri, 26 Apr 2002 16:00:10 -0400 Received: by sc-msexch-10.extremenetworks.com with Internet Mail Service (5.5.2653.19) id ; Fri, 26 Apr 2002 13:00:30 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <1B8A2DD33C49824F8D9021678C1272132287EA@sc-msexch-04.extremenetworks.com> Date: Fri, 26 Apr 2002 13:00:09 -0700 Reply-To: Mailing List Sender: Mailing List From: Shehzad Merchant Subject: Re: AW: Hide a network between two routers To: OSPF@DISCUSS.MICROSOFT.COM Below... > -----Original Message----- > From: Acee Lindem [mailto:acee@REDBACK.COM] > Sent: Friday, April 26, 2002 7:20 AM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Re: AW: Hide a network between two routers > > > Markus Prison wrote: > > Hi Acee, > > > > it will be a single broadcast network betweeen this two routers. > > For ther routers around them it should look that there is > no network between > > them. > > > > What do you meen with tunnel? > > I mean a GRE or IPIP tunnel. > > You can do it with OSPF but it is ugly. > > 1. Configure the "hidden" network in a separate area. > 2. Configure "no-advertise" ranges for the "hidden" > network. > 3. Configure a virtual link between the two routers > traversing the separate area. > You'd probably still get a ttl decrement when forwarding traffic. Not clear if the intent is to avoid that... -Shehzad > > > > > Markus > > > > -----Ursprungliche Nachricht----- > > Von: Mailing List [mailto:OSPF@DISCUSS.MICROSOFT.COM]Im > Auftrag von Acee > > Lindem > > Gesendet: Freitag, 26. April 2002 15:55 > > An: OSPF@DISCUSS.MICROSOFT.COM > > Betreff: Re: Hide a network between two routers > > > > > > Markus Prison wrote: > > > >>Hi people, > >> > >>my question will be if it's possible to hide a network > between two routers > >>for the routers that are connected to them within the ospf standard. > >> > > > > What do you mean by hide - is it a single network? The > simple answer would > > be to configure a tunnel between the two routers and run > OSPF over the > > tunnel rather than the physical network you are trying to hide. > > > > > >>When it's not possible what do you suggest what changes i > must do in my > >>ospf code of the two routers. > >> > >> > >> > > > > > > -- > > Acee > > > > > > > -- > Acee > From owner-ospf@DISCUSS.MICROSOFT.COM Fri Apr 26 18:29:53 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21243 for ; Fri, 26 Apr 2002 18:29:52 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <15.F6DC6ED3@PEAR.EASE.LSOFT.COM>; Fri, 26 Apr 2002 18:29:32 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 923675 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 26 Apr 2002 18:29:52 -0400 Received: from 207.217.120.74 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Fri, 26 Apr 2002 18:29:52 -0400 Received: from user-38lc0m4.dialup.mindspring.com ([209.86.2.196] helo=earthlink.net) by falcon.prod.itd.earthlink.net with esmtp (Exim 3.33 #2) id 171EDu-00026O-00 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 26 Apr 2002 15:29:51 -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: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3CC9D6B4.8BAF6EBB@earthlink.net> Date: Fri, 26 Apr 2002 15:37:40 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: draft..-congest-control-00.txt : New sect To: OSPF@DISCUSS.MICROSOFT.COM Content-Transfer-Encoding: 7bit Vishwas, I guess it is, except... 1) RFC3137 is specific to Stub Routers and my suggestion isn't. 2) If the local router is experiencing congestion, and delays SPF computation, then this router should not be used to forward data packets, if there is an alternate available that is not congested. 3) If there are legacy routers that don't yet support one or more items that you suggested in your draft, then this would be better than nothing. A) *** Because of 5) B) *** Could be used as part of 4.1.3 "Use of other Control Packets to Detect Live-ness" ... --- Ditto the B as it was implicitly suggested in your draft..(Not caring about legacy routers). 4) If there are multiple routers in the area that are all experiencing local/internal congestion. 4.1) An additional item that set the DNA (do not age bit) would decrease the amount of work being done by the lsdb scaning proc in the router that rcv's and processes the LSAs. This would also decrease the number of originated control LSAa over time.. 4.2) Yes, then if the congestion was being experienced by a number of routers, after the initial flood, and the congestion subsided. There could be a excessive amount of flooding to reset the cost metric if they all experienced the subsiding of congestion simultaneously. To resolve this they should probably by default do a random time for the reflood to happen. This should flatten our a storm of broadcasts... ( Or what you did in 4.2.2.2 MAY be ok). Yes, I have atleast 1 sugestion here.. It has to do with the scalability of this value. As the number of routers supported on this interface increasses, the total number of LSAs that can be flooded increases.. Yuck... Shouldn't it be inversely scaled as the number of routers on the interface increases? (MAX_LSA_FLOOD) And limit each router on that interface to this other value. But what do you start with? What happens if you have a router sharing this interface that doesn't support this "flood limit". Should you decrease based on the neighbor's amount of flooding? This needs some thinking... 5) Depending on the architecture of the OSPF speaking router, the processing / forwarding may consume some resources that should be being used for the control packets. And thus take longer for the congestion to subside.. Mitchell Erblich PS: I am still thinking of how to specify my other 2+ suggestions. ===================== "Manral, Vishwas" wrote: > > Mitchell, > > Thanks for the nice idea you have given. A thing similar to what you have > said exists in OSPF, check RFC3137 - OSPF Stub Router Advertisement. > > The idea however does not help much in the case of congestion caused by > control protocols traffic, as the flooding still takes place normally, > though the data traffic may be reduced. We are trying to focus more on > reducing control traffic here. > > Thanks, > Vishwas > > -----Original Message----- > From: Erblichs [mailto:erblichs@EARTHLINK.NET] > Sent: Friday, April 26, 2002 10:29 PM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Re: draft..-congest-control-00.txt : New sect > > Suggestion for a new section... > Sorry, I have done alot of work with congestion and scaling... > > With the assumption of heterogeneous devices that support > different levels of support for congestion, I would to > add something like the following for the legacy devices. > > With the knowledge of sustained local congestion, some > processes may have delayed processing of such items > as the Link State database (See the 4.2.2.4 section). > > Thus, to support the legacy devices it is suggested that > some flooding of originated LSAs with excessively high > link cost metrics be done. This value should be set to > LSInfinity or a close approximate value. This should minimize > the use of this congested router as a transit router > while under congestion... > > When congestion subsides the LSAs may be re-flooded with the > appropriate costs of this non-congested link. > > Mitchell Erblich From owner-ospf@DISCUSS.MICROSOFT.COM Sat Apr 27 03:26:47 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28332 for ; Sat, 27 Apr 2002 03:26:46 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <1.FEA93739@PEAR.EASE.LSOFT.COM>; Sat, 27 Apr 2002 3:26:26 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 925056 for OSPF@DISCUSS.MICROSOFT.COM; Sat, 27 Apr 2002 03:26:45 -0400 Received: from 198.62.10.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Sat, 27 Apr 2002 03:26:45 -0400 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <2PDRJ15K>; Sat, 27 Apr 2002 03:26:39 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Sat, 27 Apr 2002 03:26:18 -0400 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: draft..-congest-control-00.txt : New sect To: OSPF@DISCUSS.MICROSOFT.COM Hi Mitchell, Comments inline. Thanks, Vishwas -----Original Message----- From: Erblichs [mailto:erblichs@EARTHLINK.NET] Sent: Saturday, April 27, 2002 4:08 AM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: draft..-congest-control-00.txt : New sect I guess it is, except... 1) RFC3137 is specific to Stub Routers and my suggestion isn't. VM> What do you mean by stub routers, routers in stub areas? The abstract of RFC3137 says: - This memo describes a backward-compatible technique that may be used by OSPF (Open Shortest Path First) implementations to advertise unavailability to forward transit traffic or to lower the preference level for the paths through such a router. In some cases, it is desirable not to route transit traffic via a specific OSPF router. However, OSPF does not specify a standard way to accomplish this. Isnt this what you desire? 2) If the local router is experiencing congestion, and delays SPF computation, then this router should not be used to forward data packets, if there is an alternate available that is not congested. 3) If there are legacy routers that don't yet support one or more items that you suggested in your draft, then this would be better than nothing. A) *** Because of 5) B) *** Could be used as part of 4.1.3 "Use of other Control Packets to Detect Live-ness" ... --- Ditto the B as it was implicitly suggested in your draft..(Not caring about legacy routers). VM> I am sorry I did not understand. However some existing OSPF implementations already use control packets as surrogate hellos. There is never any talk of "legacy routers". ;-) 4) If there are multiple routers in the area that are all experiencing local/internal congestion. 4.1) An additional item that set the DNA (do not age bit) would decrease the amount of work being done by the lsdb scaning proc in the router that rcv's and processes the LSAs. This would also decrease the number of originated control LSAa over time.. VM> How LSDB refreshing(scanning) is done, is done differently by implementatons. We can use DNA bit however with the other methods in place, we can do without this(there would be other additonal issues which would prop up) 4.2) Yes, then if the congestion was being experienced by a number of routers, after the initial flood, and the congestion subsided. There could be a excessive amount of flooding to reset the cost metric if they all experienced the subsiding of congestion simultaneously. To resolve this they should probably by default do a random time for the reflood to happen. This should flatten our a storm of broadcasts... ( Or what you did in 4.2.2.2 MAY be ok). Yes, I have atleast 1 sugestion here.. It has to do with the scalability of this value. As the number of routers supported on this interface increasses, the total number of LSAs that can be flooded increases.. Yuck... Shouldn't it be inversely scaled as the number of routers on the interface increases? (MAX_LSA_FLOOD) And limit each router on that interface to this other value. But what do you start with? What happens if you have a router sharing this interface that doesn't support this "flood limit". Should you decrease based on the neighbor's amount of flooding? This needs some thinking... VM> As I told you we are trying to focus on reducing control plane traffic. So this case does not arise. 5) Depending on the architecture of the OSPF speaking router, the processing / forwarding may consume some resources that should be being used for the control packets. And thus take longer for the congestion to subside.. VM> Ok. Thanks again. "Manral, Vishwas" wrote: > > Mitchell, > > Thanks for the nice idea you have given. A thing similar to what you have > said exists in OSPF, check RFC3137 - OSPF Stub Router Advertisement. > > The idea however does not help much in the case of congestion caused by > control protocols traffic, as the flooding still takes place normally, > though the data traffic may be reduced. We are trying to focus more on > reducing control traffic here. > > Thanks, > Vishwas > > -----Original Message----- > From: Erblichs [mailto:erblichs@EARTHLINK.NET] > Sent: Friday, April 26, 2002 10:29 PM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Re: draft..-congest-control-00.txt : New sect > > Suggestion for a new section... > Sorry, I have done alot of work with congestion and scaling... > > With the assumption of heterogeneous devices that support > different levels of support for congestion, I would to > add something like the following for the legacy devices. > > With the knowledge of sustained local congestion, some > processes may have delayed processing of such items > as the Link State database (See the 4.2.2.4 section). > > Thus, to support the legacy devices it is suggested that > some flooding of originated LSAs with excessively high > link cost metrics be done. This value should be set to > LSInfinity or a close approximate value. This should minimize > the use of this congested router as a transit router > while under congestion... > > When congestion subsides the LSAs may be re-flooded with the > appropriate costs of this non-congested link. > > Mitchell Erblich From owner-ospf@DISCUSS.MICROSOFT.COM Mon Apr 29 10:56:18 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15138 for ; Mon, 29 Apr 2002 10:56:17 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <10.F8E041E4@PEAR.EASE.LSOFT.COM>; Mon, 29 Apr 2002 10:55:56 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 931188 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 29 Apr 2002 10:56:18 -0400 Received: from 144.254.15.119 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Mon, 29 Apr 2002 10:56:17 -0400 Received: from ASMIRNOVW2K (dhcp-bru-peg2-vl26-144-254-9-171.cisco.com [144.254.9.171]) by strange-brew.cisco.com (8.8.8+Sun/8.8.8) with SMTP id QAA09204 for ; Mon, 29 Apr 2002 16:56:16 +0200 (MET DST) References: 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Message-ID: <023d01c1ef8e$018f5650$ab09fe90@cisco.com> Date: Mon, 29 Apr 2002 16:56:12 +0200 Reply-To: Mailing List Sender: Mailing List From: Anton Smirnov Organization: Cisco Systems, Inc. Subject: Re: AW: Hide a network between two routers To: OSPF@DISCUSS.MICROSOFT.COM Content-Transfer-Encoding: 7bit Markus, if I understood correctly, by 'hiding' the network you mean announcing it in a way that all non connected routers know about the link and may use it for transit traffic but are not aware of addressing associated with the network. If above is correct then it is very easy to achieve. Just announce this broadcast link in type-1 LSAs of both connected routers as type-1 link (you wrote there are two routers on the link, right?). This change is seamless for all non-connected routers. For connected routers it will require minor changes in LSA origination code and, may be, in SPF code to calculate correctly next hop information. Couple of years ago I played with this mechanism to achieve LSDB size reduction for networks actively using broadcast media to interconnect two routers (say, Ethernet crossover connections between routers). Goal was different from what you are trying to achieve, because accent was on autoconfiguration of the feature without involving much additional signaling, and transit network addressing was still announced. But I remember that actual code changes for this feature were very minimal. That time I half-wrote a paper about this mechanism. If you are interested I can find it, though I don't think it is of much help for your task. Anton ----- Original Message ----- From: "Markus Prison" To: Sent: Friday, April 26, 2002 16:11 Subject: [OSPF] AW: Hide a network between two routers > Hi Acee, > > it will be a single broadcast network betweeen this two routers. > For ther routers around them it should look that there is no network between > them. > > What do you meen with tunnel? > > Markus > > -----Ursprungliche Nachricht----- > Von: Mailing List [mailto:OSPF@DISCUSS.MICROSOFT.COM]Im Auftrag von Acee > Lindem > Gesendet: Freitag, 26. April 2002 15:55 > An: OSPF@DISCUSS.MICROSOFT.COM > Betreff: Re: Hide a network between two routers > > > Markus Prison wrote: > > Hi people, > > > > my question will be if it's possible to hide a network between two routers > > for the routers that are connected to them within the ospf standard. > > What do you mean by hide - is it a single network? The simple answer would > be to configure a tunnel between the two routers and run OSPF over the > tunnel rather than the physical network you are trying to hide. > > > > > When it's not possible what do you suggest what changes i must do in my > > ospf code of the two routers. > > > > > > > -- > Acee > From owner-ospf@DISCUSS.MICROSOFT.COM Mon Apr 29 11:18:28 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17514 for ; Mon, 29 Apr 2002 11:18:27 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <3.F8156239@PEAR.EASE.LSOFT.COM>; Mon, 29 Apr 2002 11:18:06 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 931248 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 29 Apr 2002 11:18:28 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Mon, 29 Apr 2002 11:18:28 -0400 Received: from redback.com (login003.redback.com [155.53.12.55]) by prattle.redback.com (Postfix) with ESMTP id A23A3CAB74 for ; Mon, 29 Apr 2002 08:18:26 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020205 X-Accept-Language: en-us MIME-Version: 1.0 References: <023d01c1ef8e$018f5650$ab09fe90@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3CCD645F.708@redback.com> Date: Mon, 29 Apr 2002 11:18:55 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: AW: Hide a network between two routers To: OSPF@DISCUSS.MICROSOFT.COM Content-Transfer-Encoding: 7bit Anton, Along these same lines there is also: http://www.ietf.org/internet-drafts/draft-ietf-isis-igp-p2p-over-lan-00.txt Of course, to hide the network completely you have to treat the ethernet as an unnumbered point-to-point interface. Anton Smirnov wrote: > Markus, > if I understood correctly, by 'hiding' the network you mean announcing it > in a way that all non connected routers know about the link and may use it > for transit traffic but are not aware of addressing associated with the > network. > If above is correct then it is very easy to achieve. Just announce this > broadcast link in type-1 LSAs of both connected routers as type-1 link (you > wrote there are two routers on the link, right?). This change is seamless > for all non-connected routers. For connected routers it will require minor > changes in LSA origination code and, may be, in SPF code to calculate > correctly next hop information. > > Couple of years ago I played with this mechanism to achieve LSDB size > reduction for networks actively using broadcast media to interconnect two > routers (say, Ethernet crossover connections between routers). Goal was > different from what you are trying to achieve, because accent was on > autoconfiguration of the feature without involving much additional > signaling, and transit network addressing was still announced. But I > remember that actual code changes for this feature were very minimal. That > time I half-wrote a paper about this mechanism. If you are interested I can > find it, though I don't think it is of much help for your task. > > Anton > > > ----- Original Message ----- > From: "Markus Prison" > To: > Sent: Friday, April 26, 2002 16:11 > Subject: [OSPF] AW: Hide a network between two routers > > > >>Hi Acee, >> >>it will be a single broadcast network betweeen this two routers. >>For ther routers around them it should look that there is no network >> > between > >>them. >> >>What do you meen with tunnel? >> >>Markus >> >>-----Ursprungliche Nachricht----- >>Von: Mailing List [mailto:OSPF@DISCUSS.MICROSOFT.COM]Im Auftrag von Acee >>Lindem >>Gesendet: Freitag, 26. April 2002 15:55 >>An: OSPF@DISCUSS.MICROSOFT.COM >>Betreff: Re: Hide a network between two routers >> >> >>Markus Prison wrote: >> >>>Hi people, >>> >>>my question will be if it's possible to hide a network between two >>> > routers > >>>for the routers that are connected to them within the ospf standard. >>> >>What do you mean by hide - is it a single network? The simple answer would >>be to configure a tunnel between the two routers and run OSPF over the >>tunnel rather than the physical network you are trying to hide. >> >> >>>When it's not possible what do you suggest what changes i must do in my >>>ospf code of the two routers. >>> >>> >>> >> >>-- >>Acee >> >> > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Mon Apr 29 12:50:23 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27650 for ; Mon, 29 Apr 2002 12:50:22 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <13.FAC419F2@PEAR.EASE.LSOFT.COM>; Mon, 29 Apr 2002 12:49:58 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 931465 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 29 Apr 2002 12:50:20 -0400 Received: from 144.254.15.119 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Mon, 29 Apr 2002 12:50:20 -0400 Received: from ASMIRNOVW2K (dhcp-bru-peg2-vl26-144-254-9-171.cisco.com [144.254.9.171]) by strange-brew.cisco.com (8.8.8+Sun/8.8.8) with SMTP id SAA17718 for ; Mon, 29 Apr 2002 18:50:18 +0200 (MET DST) References: <023d01c1ef8e$018f5650$ab09fe90@cisco.com> <3CCD645F.708@redback.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_02ED_01C1EFAE.B2BE04B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Message-ID: <02f001c1ef9d$ef5e6790$ab09fe90@cisco.com> Date: Mon, 29 Apr 2002 18:50:14 +0200 Reply-To: Mailing List Sender: Mailing List From: Anton Smirnov Organization: Cisco Systems, Inc. Subject: Re: AW: Hide a network between two routers To: OSPF@DISCUSS.MICROSOFT.COM This is a multi-part message in MIME format. ------=_NextPart_000_02ED_01C1EFAE.B2BE04B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Acee, I didn't mention this paper to Markus just because it is also not exactly what he needs. OSPF standard says that point-to-point interfaces do not need to use IP address of neighbor in next-hop calculation, but this information is anyway readily available and can be used if wanted to. So from OSPF perspective, ptp operations on broadcast media happen almost automatically after implementing initial standard - if proper method to configure such interface as ptp has been provided, of course - and are working in several implementations for many years. It is right thing to document it, though. Network operator has to configure broadcast links to be ptp if he wants them to. So what I was interested in is, actually, method selfconfiguring broadcast links as ptp if they are being used as ptp. It, obviously, makes no sense without possibility to use broadcast links as ptp, but latter has already been working in implementation I played with and I took it for granted :-) I'm attaching the paper I mentioned, I hope it will explain technical side better. I remembered it when I wrote email to Markus because he may need to touch same areas of code and do something resemble. He needs to think of all procedures himself, though, as his task seems to be rather unusual. The paper is rather clumsy and heavy worded, but technical side is simple. Anton ----- Original Message ----- From: "Acee Lindem" To: Sent: Monday, April 29, 2002 17:18 Subject: Re: [OSPF] AW: Hide a network between two routers > Anton, > > Along these same lines there is also: > > http://www.ietf.org/internet-drafts/draft-ietf-isis-igp-p2p-over-lan-00.txt > > Of course, to hide the network completely you have to treat the ethernet > as an unnumbered point-to-point interface. > > Anton Smirnov wrote: > > Markus, > > if I understood correctly, by 'hiding' the network you mean announcing it > > in a way that all non connected routers know about the link and may use it > > for transit traffic but are not aware of addressing associated with the > > network. > > If above is correct then it is very easy to achieve. Just announce this > > broadcast link in type-1 LSAs of both connected routers as type-1 link (you > > wrote there are two routers on the link, right?). This change is seamless > > for all non-connected routers. For connected routers it will require minor > > changes in LSA origination code and, may be, in SPF code to calculate > > correctly next hop information. > > > > Couple of years ago I played with this mechanism to achieve LSDB size > > reduction for networks actively using broadcast media to interconnect two > > routers (say, Ethernet crossover connections between routers). Goal was > > different from what you are trying to achieve, because accent was on > > autoconfiguration of the feature without involving much additional > > signaling, and transit network addressing was still announced. But I > > remember that actual code changes for this feature were very minimal. That > > time I half-wrote a paper about this mechanism. If you are interested I can > > find it, though I don't think it is of much help for your task. > > > > Anton > > > > > > ----- Original Message ----- > > From: "Markus Prison" > > To: > > Sent: Friday, April 26, 2002 16:11 > > Subject: [OSPF] AW: Hide a network between two routers > > > > > > > >>Hi Acee, > >> > >>it will be a single broadcast network betweeen this two routers. > >>For ther routers around them it should look that there is no network > >> > > between > > > >>them. > >> > >>What do you meen with tunnel? > >> > >>Markus > >> > >>-----Ursprungliche Nachricht----- > >>Von: Mailing List [mailto:OSPF@DISCUSS.MICROSOFT.COM]Im Auftrag von Acee > >>Lindem > >>Gesendet: Freitag, 26. April 2002 15:55 > >>An: OSPF@DISCUSS.MICROSOFT.COM > >>Betreff: Re: Hide a network between two routers > >> > >> > >>Markus Prison wrote: > >> > >>>Hi people, > >>> > >>>my question will be if it's possible to hide a network between two > >>> > > routers > > > >>>for the routers that are connected to them within the ospf standard. > >>> > >>What do you mean by hide - is it a single network? The simple answer would > >>be to configure a tunnel between the two routers and run OSPF over the > >>tunnel rather than the physical network you are trying to hide. > >> > >> > >>>When it's not possible what do you suggest what changes i must do in my > >>>ospf code of the two routers. > >>> > >>> > >>> > >> > >>-- > >>Acee > >> > >> > > > > > -- > Acee > ------=_NextPart_000_02ED_01C1EFAE.B2BE04B0 Content-Type: application/octet-stream; name="CSCdt21771" Content-Disposition: attachment; filename="CSCdt21771" Content-Transfer-Encoding: quoted-printable 
=0A=
Summary of operations=0A=
=0A=
   In summary, initially OSPF announces (or at least prepares to do=0A=
that) all broadcast and NBMA interfaces in originated Router LSA as if=0A=
they were point-to-point links with 0 or 1 neighbor. At the same time=0A=
all basic functions like DR/BDR elections, neighbor discovery and=0A=
flooding thru the interface remain unmodified. OSPF monitors for some=0A=
events which can force interface to be announced as transit=0A=
network. These events include (but not limited to) discovery that=0A=
interface is used to communicate with more than one neighbor and that=0A=
router neighboring thru the interface doesn't support this=0A=
feature. Once reverted to classic behavior, OSPF doesn't try to=0A=
reactivate the feature as number of neighbors on interface changes.=0A=
   =0A=
   In most practical cases OSPF will disable the feature on interface=0A=
which can't support it even before first adjacency reaches FULL state.=0A=
=0A=
=0A=
Detailed description of the behavior=0A=
=0A=
   Implementation supporting this specification keeps one more data=0A=
field in its Interface Data Structure (section 9 of RFC2328).=0A=
=0A=
PtpTentative=0A=
   Boolean flag determining if interface should be advertised as=0A=
Point-to-point link. When flag is cleared (i.e. have False value),=0A=
interface behavior and advertisement is fully compatible with=0A=
'classic' behavior.=0A=
=0A=
   This flag can be set only when interface first comes up. To=0A=
eliminate LSA flapping and speed up convergence in no other=0A=
circumstances flag can be set to True if it was cleared during=0A=
interface operations. To facilitate setting the flag, one action is=0A=
modified for Interface state machine (see section 9.3).=0A=
=0A=
State: Down=0A=
Event: InterfaceUp=0A=
New state: Depends upon action routine=0A=
=0A=
Action: in addition to actions specified by RFC, set PtpTentative flag=0A=
to True if interface type is broadcast or NBMA and at most one=0A=
neighbor is attached to the interface. Otherwise PtpTentative flag is=0A=
set to False. Please note that there can be more than one neighbor (in=0A=
Down state) attached to NBMA interface thru manual configuration.=0A=
Accordingly to above criteria such NBMA interface will have=0A=
PtpTentative flag cleared from interface initialization.=0A=
=0A=
=0A=
Reverting to announcing interface as multiaccess subnetwork=0A=
=0A=
   This section discusses events which must be monitored to detect=0A=
when interface must no longer be advertised as point-to-point=0A=
connection. In brief, OSPF a) checks Hello packets received on the=0A=
interface with PtpTentative flag set for signs that more than one=0A=
neighbor reachable thru it; and b) monitors neighbor's representation=0A=
of the network to verify that it is capable of and willing to=0A=
participate in presenting network to other routers in the area as=0A=
point-to-point link.=0A=
=0A=
 Modifications to processing received Hello Packet=0A=
=0A=
   Section 10.5 of RFC, describing processing of received Hello=0A=
Packets, modified to detect presence of more than one OSPF speaker on=0A=
the interface. Intention is to detect this condition as early as=0A=
possible, because it could conserve us from re-originating our Router=0A=
LSA.=0A=
=0A=
   First check specific for implementation supporting this=0A=
specification is done after new neighbor data structure was created as=0A=
a result of Hello packet processing (i.e. neighbor is heard for the=0A=
first time). If PtpTentative flag is set on interface with which newly=0A=
created neighbor is associated then check number of neighbors attached=0A=
to the interface. If current number of neighbors (including newly=0A=
created neighbor) is greater than one then clear the PtpTentative flag=0A=
on this interface.=0A=
=0A=
   Another check is being done after event HelloReceived was processed=0A=
for the neighbor. While examining list of neighbors in this Hello=0A=
packet to determine if 1-WayReceived or 2-WayReceived event should be=0A=
generated for the neighbor, number of neighbors listed in received=0A=
Hello packet as recently heard should be noted. If PtpTentative flag=0A=
is set on the interface and either number of listed neighbors is=0A=
greater than 1 or only one neighbor is listed and ID of the listed=0A=
neighbor is not equal to router-id of local OSPF process, then=0A=
PtpTentative flag for the interface must be cleared.=0A=
=0A=
   In both these cases, when PtpTentative flag is first cleared on the=0A=
interface , OSPF must check if LSA(s) origination is necessary to=0A=
describe the link accurately.=0A=
=0A=
- if interface state is greater than Waiting, then origination of=0A=
Router LSA must be scheduled=0A=
=0A=
- in addition, if interface state is DR, then generation of Network=0A=
LSA describing broadcast network attached to the interface must be=0A=
scheduled=0A=
=0A=
=0A=
 Modifications to installing LSA-s in the LSDB=0A=
=0A=
   Section 13.2 of RFC, describing procedures to install new (received=0A=
over flooding or self-originated) LSA into the LSDB, modified to=0A=
facilitate mechanism detecting support by neighbor of presenting=0A=
broadcast network as point-to-point link. Neighbor might prefer=0A=
treating interconnecting link as multiaccess network even if it=0A=
supports current specification (for example, it 'remembers' presence=0A=
of third router on the network).=0A=
=0A=
   If new Router LSA being installed into the LSDB and as part of=0A=
required by RFC check it was discovered that this LSA is different=0A=
from its previous copy in terms of topological meaning (i.e. excluding=0A=
difference in Sequence Number and LS Checksum), then additional checks=0A=
must be performed before scheduling SPF run:=0A=
=0A=
- Search for neighbors with Router ID equal to Link State ID of newly=0A=
installed LSA on all interfaces belonging to the same area and with=0A=
PtpTentative flag set to True=0A=
=0A=
- For each such neighbor do lookup in newly installed Router LSA for=0A=
link with Type equal 2 (transit network), Link ID equal to IP address=0A=
of Designated Router elected on interface thru which this neighbor is=0A=
known, and Link Data equal to IP address of the neighbor's interface=0A=
in this subnetwork (RFC requires this address to be kept as part of=0A=
neighbor's data structure)=0A=
=0A=
- If (and only if) this lookup succeeds (i.e. our neighbor has=0A=
announced link with such properties in its Router LSA) then clear=0A=
PtpTentative flag on the interface with which the neighbor is=0A=
associated and schedule (re)origination of own Router LSA. If=0A=
interface with just cleared PtpTentative flag is in DR state, then=0A=
origination of Network LSA for subnetwork on this interface is also=0A=
scheduled=0A=
=0A=
   Note that implementation must walk thru whole list of neighbors=0A=
found in the first step of described procedure. Local router might=0A=
have more than one established adjacency with router represented by=0A=
newly installed LSA and PtpTentative flag can be cleared on more than=0A=
one interface as a result of processing single Router LSA. On the=0A=
other hand, implementation must NOT assume that if one interface was=0A=
converted to be announced as broadcast as a result of previous=0A=
processing then PtpTentative flag can also be cleared on all=0A=
interfaces thru which this neighbor is known. Even when neighbor=0A=
supports current optimization scheme and currently local router is the=0A=
only peer reachable thru the interface, neighbor can, for example,=0A=
prefer to treat this interface as broadcast because it remembers=0A=
concurrent reachability of more than one OSPF speaker thru the=0A=
subnetwork.=0A=
=0A=
   After actions described above, OSPF proceeds to procedure of=0A=
scheduling SPF run as described further by RFC. However, implementation=0A=
might choose skipping scheduling SPF run at this stage if Router LSA=0A=
re-origination has just been scheduled. After OSPF produces new Router=0A=
LSA and installs it in the LSDB, procedure of insertion new Router LSA=0A=
will run again (and this time it shouldn't clear any PtpTentative=0A=
flags because router installs self-originated Router LSA). =0A=
=0A=
=0A=
LSA origination procedure modifications=0A=
=0A=
   Modifications to original OSPF specification described above are=0A=
only for keeping flag PtpTentative in the most accurate state. The=0A=
only area where current specification alters logic of the 'classic'=0A=
OSPF behavior is LSA origination. While originating LSA-s describing IP=0A=
network attached to interface and adjacencies thru it, OSPF consults=0A=
the flag to determine if IP network should be advertised in=0A=
'classical' or 'optimized' manner.=0A=
=0A=
   Implementation must never originate Network LSA describing IP=0A=
subnetwork, connected to interface with PtpTentative flag set. =0A=
   If OSPF process receives self-originated Network LSA, describing=0A=
the network connected to interface with PtpTentative flag set, then=0A=
this LSA should be flashed from OSPF domain. Note that this behavior=0A=
is fully compliant with current OSPF practice. I.e., if we are not DR=0A=
on the interface or we have no adjacencies thru it, then LSA is=0A=
flushed anyway. If router is DR, has at least one full adjacency thru=0A=
the interface and still has PtpTentative flag set on it, then Net LSA=0A=
most probably won't be needed for the subnetwork.=0A=
=0A=
   10 reasons why Router LSA can be re-originated described in section=0A=
12.4 of RFC are, basically, remain intact. All rules described above=0A=
are covered by item (2) (router interface's state changes),=0A=
understanding interface state as combination of State and PtpTentative=0A=
data.=0A=
=0A=
   Origination of Router LSA, as described in 12.4.1.2 of OSPF,=0A=
enhanced by additional clause put after check if interface State is=0A=
Waiting:=0A=
=0A=
o Else (i.e. if interface state is greater than Waiting), if=0A=
PtpTentative flag is set to True for this interface and router is=0A=
fully adjacent with a neighbor thru the interface, then add to LSA=0A=
Type-1 link (point-to-point). Link ID of it set to Router-ID of the=0A=
neighbor adjacent thru the interface; Link Data field is set to IP=0A=
interface address; and cost equal to interface output cost. In=0A=
addition, generate Type-3 link (stub network) with Link ID set to=0A=
subnet's IP address, Link Data to the subnet's mask, and the cost to=0A=
interface's output cost.=0A=
   If PtpTentative flag is set for the interface but no neighbor is=0A=
fully adjacent thru it, then describe the link as if interface's state=0A=
were Waiting (i.e. add Type-3 link only, see first clause in 12.4.1.2=0A=
of RFC).=0A=
=0A=
SPF next-hop procedure modification=0A=
=0A=
SPF must use for next hop calculation via interface with PtpTentative=0A=
flag set same data as for broadcast interfaces (i.e. combination of=0A=
output interface/next hop IP address).=0A=
=0A=
=0A=
Compatibility issues.=0A=
=0A=
   Behavior of router implementing these recommendations is 100%=0A=
compatible with systems not supporting it. If both routers connected=0A=
with a such ptp-like broadcast link and they choose advertise link as=0A=
point-to-point, generated LSA-s are fully compatible with standard=0A=
implementation; all systems in the area, both implementing this=0A=
specification and not, will benefit from reduced LSDB size and=0A=
flooding.=0A=
   Furthermore, this mechanism doesn't require routers on both sides=0A=
of the link implement proposal to achieve LSDB reduction. If one side=0A=
of the link has OSPF implementation without support of the feature,=0A=
but manually configured to treat this interface as point-to-point,=0A=
then peer router supporting enhancement will (after interface restart)=0A=
successfully 'negotiate' announcing link as ptp to the rest of area.=0A=
=0A=
   Possible negative side effects of implementing this technique are=0A=
very low. =0A=
   Worst case scenario is:=0A=
- There are two routers on broadcast network; they have reached FULL=0A=
state and negotiated to announce the link as ptp=0A=
- Third router (either supporting this document or not) enters the LAN=0A=
for the first time since previous pair concurrently restarted their=0A=
OSPF processes=0A=
- One of the previously operating routers delays originating his=0A=
updated LSA(s) comparing with another router for more than interval=0A=
between scheduling SPF run and executing it;=0A=
=0A=
then this link will be ineligible for transit traffic and being=0A=
avoided for up to minimum interval allowed between two consecutive SPF=0A=
runs.=0A=
   =0A=
   Nevertheless, this worst case scenario should be extremely rare in=0A=
live networks as it requires that all (i.e. 3 or more) routers=0A=
connected to broadcast network went down at the same time.=0A=
=0A=
   More probable is situation when newly established adjacency is=0A=
unusable up to minimum interval of time allowed between two=0A=
consecutive SPF runs. In other words, interval of time between first=0A=
Hello exchange and availability for transit traffic can be slightly=0A=
increased. It is small interval and dialup lines (which supposed to go=0A=
up/down frequently) cannot be affected by it, so refreshing and=0A=
running SPF on reduced LSDB size will give in a long run more benefits=0A=
than possible short delays at interface startup.=0A=
=0A=
=0A=
Discussion=0A=
=0A=
Benefits of the mechanism:=0A=
=0A=
- Relatively easy to implement as all base functions (flooding, SPF,=0A=
LSDB refresh management etc.) remain unmodified. No new signalling=0A=
outside the router has been introduced. All changes should be limited=0A=
to 50-70 new lines of code=0A=
=0A=
- Feature's benefits (i.e. database size reduction) for each=0A=
particular network can range from none to significant; negative side=0A=
effects are very small. Nicely, negative impact is proportional to=0A=
potential benefit. I.e. the less is benefit that feature can give for=0A=
particular network due to its topology, the higher probability that it=0A=
even wouldn't be possible to determine outside of the router if it=0A=
supports current protocol enhancement or not=0A=
=0A=
Drawbacks of the mechanism:=0A=
=0A=
- To enhance stability in LSA-s, current mechanism doesn't allow set=0A=
PtpTentative flag back if all or all but one neighbors on the=0A=
interface went down. Apparently, both adjacent routers should reset=0A=
their interfaces at the same time after software on both of them=0A=
started supporting the feature. Otherwise running router will infect=0A=
restarting neighbor with memory of times long gone. So it may take=0A=
very long time before routers discover that there is no need to=0A=
simulate old behavior anymore=0A=
=0A=
- If both routers are using this technique and one of them suddenly=0A=
changes its router ID (for example, due to manual configuration), then=0A=
its peer might see two neighbors on the interface for as long as=0A=
HoldTime interval. It will force OSPF to believe that interface should=0A=
be reverted to broadcast operations.=0A=
=0A= =0A= =0A= ------=_NextPart_000_02ED_01C1EFAE.B2BE04B0-- From owner-ospf@DISCUSS.MICROSOFT.COM Tue Apr 30 08:57:33 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18316 for ; Tue, 30 Apr 2002 08:57:32 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <9.FF43F5D6@PEAR.EASE.LSOFT.COM>; Tue, 30 Apr 2002 8:57:09 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 935210 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 30 Apr 2002 08:57:30 -0400 Received: from 209.119.0.19 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Tue, 30 Apr 2002 08:47:30 -0400 Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <6.F94B4C9F@PEAR.EASE.LSOFT.COM>; Tue, 30 Apr 2002 8:47:09 -0400 Message-ID: Date: Tue, 30 Apr 2002 08:47:30 -0400 Reply-To: Mailing List Sender: Mailing List From: Magnus Andersson Subject: RFC vs. MIB internal metric contradiction To: OSPF@DISCUSS.MICROSOFT.COM After reading both RFC2328 and J.Moy(OSPF, Anatonomy of an Internet Routing protocol) I understand that 0 is not a valid number for the metric field in the router-LSA. However in the OSPFv2 MIB it seems that 0 is a valid value. Are there other situations where we allow a metric of 0, or why does the MIB say that we can use 0?? -- Note the OSPF Metric is defined as an unsigned value in the range Metric ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The OSPF Internal Metric." SYNTAX Integer32 (0..'FFFF'h) RFC2328: Interface output cost(s) The cost of sending a data packet on the interface, expressed in the link state metric. This is advertised as the link cost for this interface in the router-LSA. The cost of an interface must be greater than zero.Interface output cost(s) The cost of sending a data packet on the interface, expressed in the link state metric. This is advertised as the link cost for this interface in the router-LSA. The cost of an interface must be greater than zero. OSPF, Anatonomy of an Internet Routing protocol: Each link also contains a Metric field. This field ranging from 1 to 65535, indicates the relative cost of sending packets over the link. From owner-ospf@DISCUSS.MICROSOFT.COM Tue Apr 30 09:20:01 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19112 for ; Tue, 30 Apr 2002 09:19:59 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <8.E6B678E5@PEAR.EASE.LSOFT.COM>; Tue, 30 Apr 2002 9:19:36 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 935420 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 30 Apr 2002 09:19:57 -0400 Received: from 64.4.37.68 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Tue, 30 Apr 2002 09:19:57 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 30 Apr 2002 06:19:58 -0700 Received: from 155.245.254.253 by pv2fd.pav2.hotmail.msn.com with HTTP; Tue, 30 Apr 2002 13:19:58 GMT X-Originating-IP: [155.245.254.253] Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 30 Apr 2002 13:19:58.0354 (UTC) FILETIME=[B9CC5720:01C1F049] Message-ID: Date: Tue, 30 Apr 2002 13:19:58 +0000 Reply-To: Mailing List Sender: Mailing List From: wu min Subject: Virtual Link To: OSPF@DISCUSS.MICROSOFT.COM Hi, Should virtual link of a backbone area be manually configured or is there a way to dynamically establish it through OSPF protocol? If an area has 2 ABRs, X and Y, and both have direct connection to the backbone area with cost metric C1 and C2 respectively. Assuming that there exist a virtual link between these two ABRs and the cost metric of the link is C3. If C1 > C2 + C3, does it means that X will choose the virtual link instead of direct link to the backbone area? Thanx. -Tze Ven _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com From owner-ospf@DISCUSS.MICROSOFT.COM Tue Apr 30 10:24:41 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22011 for ; Tue, 30 Apr 2002 10:24:40 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <6.F94B4CA8@PEAR.EASE.LSOFT.COM>; Tue, 30 Apr 2002 10:24:18 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 935606 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 30 Apr 2002 10:24:41 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Tue, 30 Apr 2002 10:24:41 -0400 Received: from redback.com (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id CD185CAB77 for ; Tue, 30 Apr 2002 07:24:39 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020205 X-Accept-Language: en-us MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3CCEA937.5000704@redback.com> Date: Tue, 30 Apr 2002 10:24:55 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Virtual Link To: OSPF@DISCUSS.MICROSOFT.COM Content-Transfer-Encoding: 7bit wu min wrote: > Hi, > > Should virtual link of a backbone area be manually configured or is there a > way to dynamically establish it through OSPF protocol? Yes. At one time there was a draft where they where were established dynamically but it didn't garner popular support. > > If an area has 2 ABRs, X and Y, and both have direct connection to the > backbone area with cost metric C1 and C2 respectively. Assuming that there > exist a virtual link between these two ABRs and the cost metric of the link > is C3. If C1 > C2 + C3, does it means that X will choose the virtual link > instead of direct link to the backbone area? It depends on where in the backbone area you wish to go. > > Thanx. > > -Tze Ven > > > _________________________________________________________________ > Chat with friends online, try MSN Messenger: http://messenger.msn.com > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Tue Apr 30 10:30:07 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22321 for ; Tue, 30 Apr 2002 10:30:05 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <14.F575A73B@PEAR.EASE.LSOFT.COM>; Tue, 30 Apr 2002 10:29:42 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 935632 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 30 Apr 2002 10:30:05 -0400 Received: from 198.62.10.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Tue, 30 Apr 2002 10:30:05 -0400 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <2PDRJJNK>; Tue, 30 Apr 2002 10:29:58 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Tue, 30 Apr 2002 10:29:51 -0400 Reply-To: Mailing List Sender: Mailing List From: "Ramalingam, Swaminathan" Subject: Re: Virtual Link Comments: To: "made_in__china@HOTMAIL.COM" To: OSPF@DISCUSS.MICROSOFT.COM >-----Original Message----- >From: wu min [mailto:made_in__china@HOTMAIL.COM] >Sent: Tuesday, April 30, 2002 6:50 PM >To: OSPF@DISCUSS.MICROSOFT.COM >Subject: Virtual Link > > >Hi, > >Should virtual link of a backbone area be manually configured >or is there a >way to dynamically establish it through OSPF protocol? Virtual links are manually configured. But there were some attempt made by the working 3-4 years back to make OSPF detect and fix backbone area partition dynamically (Dynamic virtual link).But, i guess, nobody interested in that. >If an area has 2 ABRs, X and Y, and both have direct connection to the >backbone area with cost metric C1 and C2 respectively. >Assuming that there >exist a virtual link between these two ABRs and the cost >metric of the link >is C3. If C1 > C2 + C3, does it means that X will choose the >virtual link >instead of direct link to the backbone area? shortest path will be selected irrespective of the link i.e virtual or direct link > >Thanx. > >-Tze Ven > > >_________________________________________________________________ >Chat with friends online, try MSN Messenger: http://messenger.msn.com > From owner-ospf@DISCUSS.MICROSOFT.COM Tue Apr 30 11:39:55 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25594 for ; Tue, 30 Apr 2002 11:39:54 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <8.E6B678F1@PEAR.EASE.LSOFT.COM>; Tue, 30 Apr 2002 11:39:33 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 935900 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 30 Apr 2002 11:39:56 -0400 Received: from 64.4.37.190 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Tue, 30 Apr 2002 11:39:56 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 30 Apr 2002 08:39:55 -0700 Received: from 155.245.254.253 by pv2fd.pav2.hotmail.msn.com with HTTP; Tue, 30 Apr 2002 15:39:55 GMT X-Originating-IP: [155.245.254.253] Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 30 Apr 2002 15:39:55.0399 (UTC) FILETIME=[46D3B970:01C1F05D] Message-ID: Date: Tue, 30 Apr 2002 15:39:55 +0000 Reply-To: Mailing List Sender: Mailing List From: wu min Subject: Re: Virtual Link To: OSPF@DISCUSS.MICROSOFT.COM Thank you Acee and Ramalingam. However I am in doubt with Acee's comment. Please see my question below. >>If an area has 2 ABRs, X and Y, and both have direct connection to the >>backbone area with cost metric C1 and C2 respectively. Assuming that there >>exist a virtual link between these two ABRs and the cost metric of the >>link >>is C3. If C1 > C2 + C3, does it means that X will choose the virtual link >>instead of direct link to the backbone area? > >It depends on where in the backbone area you wish to go. Could you please explain what you mean by 'where in the backbone area'? Thanx. -Tze Ven _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com From owner-ospf@DISCUSS.MICROSOFT.COM Tue Apr 30 12:55:21 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28768 for ; Tue, 30 Apr 2002 12:55:20 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <0.EB65F439@PEAR.EASE.LSOFT.COM>; Tue, 30 Apr 2002 12:54:57 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 936074 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 30 Apr 2002 12:55:20 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Tue, 30 Apr 2002 12:55:20 -0400 Received: from redback.com (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id CA4D21DCC68 for ; Tue, 30 Apr 2002 09:55:18 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020205 X-Accept-Language: en-us MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3CCECC85.5000500@redback.com> Date: Tue, 30 Apr 2002 12:55:33 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Virtual Link To: OSPF@DISCUSS.MICROSOFT.COM Content-Transfer-Encoding: 7bit wu min wrote: > Thank you Acee and Ramalingam. > > However I am in doubt with Acee's comment. Please see my question below. > > >>> If an area has 2 ABRs, X and Y, and both have direct connection to the >>> backbone area with cost metric C1 and C2 respectively. Assuming that >>> there >>> exist a virtual link between these two ABRs and the cost metric of the >>> link >>> is C3. If C1 > C2 + C3, does it means that X will choose the virtual >>> link >>> instead of direct link to the backbone area? >> >> >> It depends on where in the backbone area you wish to go. > > > Could you please explain what you mean by 'where in the backbone area'? I mean that some destination in the backbone area may be closer via the physical interface and some may be closer via the virtual link. Your example of "C1 > C2 + C3" doesn't really provide the necessary information to determine whether the physical or virtual link will be chosen to reach a given destination in the backbone area. As Ramalingam stated, the virtual link is not treated any different from a physical P2P link in the backbone area when calculate the best route. > > Thanx. > > -Tze Ven > > _________________________________________________________________ > Join the world's largest e-mail service with MSN Hotmail. > http://www.hotmail.com > -- Acee