From owner-ospf@DISCUSS.MICROSOFT.COM Thu May 1 07:40:04 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05561 for ; Thu, 1 May 2003 07:39:49 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.009A36D5@cherry.ease.lsoft.com>; Thu, 1 May 2003 7:42:40 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 698155 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 1 May 2003 07:42:39 -0400 Received: from 47.129.242.157 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 1 May 2003 07:42:39 -0400 Received: from zbl6c012.us.nortel.com (zbl6c012.corpeast.baynetworks.com [132.245.205.62]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h41BgbX18704 for ; Thu, 1 May 2003 07:42:37 -0400 (EDT) Received: by zbl6c012.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 1 May 2003 07:42:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C30FD6.C2B30AFC" Message-ID: <6204FDDE129D364D8040A98BCCB290EF0440AC31@zbl6c004.corpeast.baynetworks.com> Date: Thu, 1 May 2003 07:42:36 -0400 Reply-To: Mailing List Sender: Mailing List From: Daniel Joyal Subject: Re: progress summary of my last set of comments To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C30FD6.C2B30AFC Content-Type: text/plain Don, That about sums it up. Thanks. -Dan > -----Original Message----- > From: Don Goodspeed [mailto:dgoodspe@EXCITE.COM] > Sent: Wednesday, April 30, 2003 6:41 PM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Re: progress summary of my last set of comments > > > All, > > So then, to summarize the results of the last two days of > email chain (see inline notes): > > > Dan and all, > > > > Couple of things from my second review that I don't know if > we want to > > address or not: 1. Configuration of a TE metric at the > interface level > > (like ISIS). > All TE items to be moved to separate MIB > > > 2. Text regarding the issue that some SNMP agents may not > be able to > > query the largest size of the ospfLsdbAdvertisement attribute. > Text to be added. > > > 3. Adding new error codes to ospfConfigErrorType: invalidLength > > (actual packet size did not match) > Will not be added. > > > , duplicateRouterIdReceived. > In progress to be added. > > > 4. Is it permitted (I can't remember) to add a single var-bind to a > > previously defined notification. If it is, can I suggest adding new > > attributes for ospfIfEventType and ospfNbrEventType to the > > IfStateChange and NbrStateChange traps? > Being investigated if this is allowed. > > Thanks for all your comments, > Don > > _______________________________________________ > Join Excite! - http://www.excite.com > The most personalized portal on the Web! > ------_=_NextPart_001_01C30FD6.C2B30AFC Content-Type: text/html RE: progress summary of my last set of comments

Don,

 That about sums it up.

Thanks.
-Dan

> -----Original Message-----
> From: Don Goodspeed [mailto:dgoodspe@EXCITE.COM]
> Sent: Wednesday, April 30, 2003 6:41 PM
> To: OSPF@DISCUSS.MICROSOFT.COM
> Subject: Re: progress summary of my last set of comments
>
>
> All,
>
> So then, to summarize the results of the last two days of
> email chain (see inline notes):
>
> > Dan and all,
> >
> > Couple of things from my second review that I don't know if
> we want to
> > address or not: 1. Configuration of a TE metric at the
> interface level
> > (like ISIS).
> <don> All TE items to be moved to separate MIB
>
> > 2. Text regarding the issue that some SNMP agents may not
> be able to
> > query the largest size of the ospfLsdbAdvertisement attribute.
> <don> Text to be added.
>
> > 3. Adding new error codes to ospfConfigErrorType: invalidLength
> > (actual packet size did not match)
> <don> Will not be added.
>
> > , duplicateRouterIdReceived.
> <don> In progress to be added.
>
> > 4. Is it permitted (I can't remember) to add a single var-bind to a
> > previously defined notification. If it is, can I suggest adding new
> > attributes for ospfIfEventType and ospfNbrEventType to the
> > IfStateChange and NbrStateChange traps?
> <don> Being investigated if this is allowed.
>
> Thanks for all your comments,
> Don
>
> _______________________________________________
> Join Excite! - http://www.excite.com
> The most personalized portal on the Web!
>

------_=_NextPart_001_01C30FD6.C2B30AFC-- From owner-ospf@DISCUSS.MICROSOFT.COM Thu May 1 08:48:21 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07070 for ; Thu, 1 May 2003 08:48:20 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.009A36F0@cherry.ease.lsoft.com>; Thu, 1 May 2003 8:51:11 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 698221 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 1 May 2003 08:51:11 -0400 Received: from 216.136.175.86 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 1 May 2003 08:51:11 -0400 Received: from [65.213.102.2] by web13507.mail.yahoo.com via HTTP; Thu, 01 May 2003 05:51:10 PDT MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20030501125110.34748.qmail@web13507.mail.yahoo.com> Date: Thu, 1 May 2003 05:51:10 -0700 Reply-To: Mailing List Sender: Mailing List From: kajol pattnaik Subject: Re: Pacing/SPFDelay/SPFHoldTime in Freeware OSPF To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Precedence: list Well, freeware GateD does not. i am not sure about zebra though. --kp --- mukul goyal wrote: > Hi all, > > I was curious if freeware OSPF implementations like > GateD/Zebra support > non-standard features like LSA pacing and > spfDelay/spfHoldTime. > > Thanks, > Mukul Goyal __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com From owner-ospf@DISCUSS.MICROSOFT.COM Thu May 1 16:47:44 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10246 for ; Thu, 1 May 2003 16:47:28 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.009A43F4@cherry.ease.lsoft.com>; Thu, 1 May 2003 16:49:48 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 699407 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 1 May 2003 16:49:48 -0400 Received: from 207.217.120.46 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 1 May 2003 16:49:48 -0400 Received: from user-2ivfn2j.dialup.mindspring.com ([165.247.220.83] helo=earthlink.net) by grebe.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 19BKzy-0003ne-00 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 01 May 2003 13:49:46 -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: <3EA6A934.1050904@redback.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3EB17FCE.ECCB649A@earthlink.net> Date: Thu, 1 May 2003 13:13:02 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: ... LastChange... Suggestion To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Acee Lindem, et al, During my quick review I did not see any support for this type of object within the OSPF MIB. I do believe that a number of current MIBs do support this type of object. Please replace the "...." or "???" with the appropriate information.. The formal suggestion would take the form of: ....LastChange OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the time of the most recent addition or deletion of an entry to/from the ????, or the most recent change in value of any objects in the ???. If no such changes have occurred since the last re-initialization of the local management subsystem, then this object contains a zero value." ::= { ????? } Thank you, Mitchell Erblich Sr Software Engineer ----------------------- Acee Lindem wrote: > > This is the start of a Working Group last call for > draft-ietf-ospf-mib-update-06.txt, OSPF Version 2 Management > Information Base. All comments must be received by Wednesday, > May 7th, 2003. > > This document reached the AD review phase once before but > we decided to add MIB support for recent OSPF extensions. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ospf-mib-update-06.txt > -- > Acee From owner-ospf@DISCUSS.MICROSOFT.COM Mon May 5 19:39:24 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21529 for ; Mon, 5 May 2003 19:39:09 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.009AC630@cherry.ease.lsoft.com>; Mon, 5 May 2003 19:41:33 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 712850 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 5 May 2003 19:41:33 -0400 Received: from 131.241.15.4 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 5 May 2003 19:41:33 -0400 Received: from netkeeper2.sj.nec.com (netkeeper2.sj.nec.com [131.241.31.10]) by mail4.nec.com (/) with ESMTP id h45NfUDo023884 for ; Mon, 5 May 2003 16:41:30 -0700 (PDT) Received: from necsun.tdd.sj.nec.com (localhost [127.0.0.1]) by netkeeper2.sj.nec.com (/) with ESMTP id h45NfOww003153 for ; Mon, 5 May 2003 16:41:24 -0700 (PDT) Received: from bunny.tdd.sj.nec.com (bunny.tdd.sj.nec.com [131.241.9.33]) by necsun.tdd.sj.nec.com (8.12.8/8.12.8) with ESMTP id h45NV03a018550 for ; Mon, 5 May 2003 16:31:01 -0700 (PDT) Received: from ems12 (ems12 [131.241.5.17]) by bunny.tdd.sj.nec.com with SMTP id h45NUxYS016734 for ; Mon, 5 May 2003 16:30:59 -0700 (PDT) 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.4133.2400 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Message-ID: <12f501c31360$c89dd180$1105f183@b90.tdd.sj.nec.com> Date: Mon, 5 May 2003 16:48:09 -0700 Reply-To: Mailing List Sender: Mailing List From: kamatchi soundaram Subject: un-num p2p clarification. To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi all, I have the following two doubts in Un-num p2p for OSPF. 1) If I bring up an un-num p2p with one of the other interface's valid ip address (ex. LAN), does the un-num p2p need to be associated with the same "AREA" with which the LAN has been associated??? or can be associated with an different area address. More clearly: The router R1 has three interfaces, but interface #1 has a valid IP address and other two are un-num p2p interfaces. So, the two un-num p2p interfaces will use the Ip address of Interface #1. Assume, the interface #1 got associated with Area 0. Now the question is, can the un-num p2p interfaces be associted to some other AREA other than AREA 0 or not?? 2) In implementation point of view: Generally the numbered p2p and ethernet interfaces will be configured as Net-number/Mask and AREA. Since in numbered IP case, each interface can be specifically configured with Net num and mask and AREA. But in the case of un-num p2p, how the configuration will be?? For example what will be the net number and mask and area configuation?? Thanks in advance, GKS. From owner-ospf@DISCUSS.MICROSOFT.COM Tue May 6 03:06:25 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10215 for ; Tue, 6 May 2003 03:06:10 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.009AD2DE@cherry.ease.lsoft.com>; Tue, 6 May 2003 3:09:05 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 713655 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 6 May 2003 03:09:05 -0400 Received: from 64.106.140.220 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 6 May 2003 03:09:05 -0400 Received: from mail.apara.com (localhost.localdomain [127.0.0.1]) by mail.apara.com (8.11.6/8.11.6) with ESMTP id h467qpJ31125 for ; Tue, 6 May 2003 13:22:51 +0530 Received: from alok ([203.124.140.101]) (authenticated) by mail.apara.com (8.11.6/8.11.6) with ESMTP id h467qf331107 for ; Tue, 6 May 2003 13:22:44 +0530 References: <12f501c31360$c89dd180$1105f183@b90.tdd.sj.nec.com> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Message-ID: <01e701c3139e$ce313e00$81c802c0@alok> Date: Tue, 6 May 2003 12:41:37 +0530 Reply-To: Mailing List Sender: Mailing List From: alok Subject: Re: un-num p2p clarification. To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list > Hi all, > > I have the following two doubts in Un-num p2p for OSPF. > > 1) If I bring up an un-num p2p with one of the other interface's valid ip > address (ex. LAN), does the un-num p2p need to be associated with the same > "AREA" with which the LAN has been associated??? or can be associated with > an different area address. > More clearly: The router R1 has three interfaces, but interface #1 has a > valid IP address and other two are un-num p2p interfaces. So, the two un-num > p2p interfaces will use the Ip address of Interface #1. Assume, the > interface #1 got associated with Area 0. Now the question is, can the un-num > p2p interfaces be associted to some other AREA other than AREA 0 or not?? hi, pardon me if this has already been asked, can u please explain as to why they would use the "IP address" of interface #1? wouldnt Link-id be "router-id"? -rgds Alok From owner-ospf@DISCUSS.MICROSOFT.COM Tue May 6 11:58:13 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27099 for ; Tue, 6 May 2003 11:58:13 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.009ADAB0@cherry.ease.lsoft.com>; Tue, 6 May 2003 12:01:07 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 715225 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 6 May 2003 12:01:07 -0400 Received: from 64.254.114.115 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 6 May 2003 12:01:07 -0400 Received: by megisto-sql1 with Internet Mail Service (5.5.2653.19) id <2XHDAP54>; Mon, 5 May 2003 19:21:28 -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: Mon, 5 May 2003 19:21:26 -0400 Reply-To: Mailing List Sender: Mailing List From: Eldose Paul Subject: SPF Calculation To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list I have a network element running OSPF connected to Foundry BigIron 5000. Both Foundry and my n/w element tells that the database synchronization is complete and the neighbors are in FULL state. When I look in the database, they LSDB seems to be same. However, Foundry do not update the routing table for the loopback addresses the n/w element advertises as a Stub network in the Rtr LSA. When I turn on the debug traces in Foundry, I see the following messages May 5 17:34:32 OSPF: Adding routing table entry for transit network 10.2.5.128 May 5 17:34:32 OSPF: skipping stub network link 172.16.1.1 May 5 17:34:32 OSPF: Calculating next hop intervening router = ac100101 May 5 17:34:32 OSPF: next hop 172.16.3.249 outgoing interface ethernet 1/1 May 5 17:34:32 OSPF: skipping stub network link 172.16.1.7 May 5 17:34:32 OSPF: skipping stub network link 172.16.8.13 May 5 17:34:32 OSPF: skipping stub network link 10.119.255.254 May 5 17:34:32 OSPF: skipping stub network link 172.16.0.13 May 5 17:34:32 OSPF: skipping stub network link 172.16.4.193 May 5 17:34:32 OSPF: Adding routing table entry for transit network 172.16.3.25 Does anyone have an idea why the Stub network link is skipped from routing calculation? Section 16 in RFC 2328 describes two step procedure for the routing table calculation. First without stub networks and then with Stub networks. thanks in advance, Eldose Paul From owner-ospf@DISCUSS.MICROSOFT.COM Tue May 6 13:11:34 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29818 for ; Tue, 6 May 2003 13:11:34 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.009ADD01@cherry.ease.lsoft.com>; Tue, 6 May 2003 13:14:28 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 715489 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 6 May 2003 13:14:28 -0400 Received: from 131.241.15.4 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 6 May 2003 13:14:27 -0400 Received: from netkeeper.sj.nec.com (netkeeper.sj.nec.com [131.241.31.2]) by mail4.nec.com (/) with ESMTP id h46HEQDo020083 for ; Tue, 6 May 2003 10:14:26 -0700 (PDT) Received: from necsun.tdd.sj.nec.com (localhost [127.0.0.1]) by netkeeper.sj.nec.com (/) with ESMTP id h46HEJqZ022336 for ; Tue, 6 May 2003 10:14:20 -0700 (PDT) Received: from bunny.tdd.sj.nec.com (bunny.tdd.sj.nec.com [131.241.9.33]) by necsun.tdd.sj.nec.com (8.12.8/8.12.8) with ESMTP id h46H3r3a025098 for ; Tue, 6 May 2003 10:03:53 -0700 (PDT) Received: from ems12 (ems12 [131.241.5.17]) by bunny.tdd.sj.nec.com with SMTP id h46H3qYS000947 for ; Tue, 6 May 2003 10:03:52 -0700 (PDT) References: <12f501c31360$c89dd180$1105f183@b90.tdd.sj.nec.com> <01e701c3139e$ce313e00$81c802c0@alok> 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.4133.2400 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Message-ID: <139a01c313f3$df429810$1105f183@b90.tdd.sj.nec.com> Date: Tue, 6 May 2003 10:21:03 -0700 Reply-To: Mailing List Sender: Mailing List From: kamatchi soundaram Subject: Re: un-num p2p clarification. To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi alok! To forward and process IP looks for valid IP address in the received packet. Since in the case of un-num p2p, there is no specific IP address in OSPF point of view, the Valid IP address of the other interface, will be used as the source IP address in the IP Header. Btw: That's the reason OSPF specifies, to configure un-num p2p to an interface of a router, the router should have atleast one valid IP address (it may be for LAN or for loop-back). GKS. ----- Original Message ----- From: "alok" To: Sent: Tuesday, May 06, 2003 12:11 AM Subject: Re: un-num p2p clarification. > > Hi all, > > > > I have the following two doubts in Un-num p2p for OSPF. > > > > 1) If I bring up an un-num p2p with one of the other interface's valid ip > > address (ex. LAN), does the un-num p2p need to be associated with the same > > "AREA" with which the LAN has been associated??? or can be associated with > > an different area address. > > More clearly: The router R1 has three interfaces, but interface #1 has a > > valid IP address and other two are un-num p2p interfaces. So, the two > un-num > > p2p interfaces will use the Ip address of Interface #1. Assume, the > > interface #1 got associated with Area 0. Now the question is, can the > un-num > > p2p interfaces be associted to some other AREA other than AREA 0 or not?? > > hi, > > pardon me if this has already been asked, > > can u please explain as to why they would use the "IP address" of interface > #1? > > wouldnt Link-id be "router-id"? > > -rgds > Alok > From owner-ospf@DISCUSS.MICROSOFT.COM Tue May 6 14:05:00 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01632 for ; Tue, 6 May 2003 14:05:00 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.009ADDDD@cherry.ease.lsoft.com>; Tue, 6 May 2003 14:07:56 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 715630 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 6 May 2003 14:07:55 -0400 Received: from 64.106.140.220 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 6 May 2003 14:07:55 -0400 Received: from mail.apara.com (localhost.localdomain [127.0.0.1]) by mail.apara.com (8.11.6/8.11.6) with ESMTP id h46IprJ17874 for ; Wed, 7 May 2003 00:21:53 +0530 Received: from apara.com (localhost.localdomain [127.0.0.1]) by mail.apara.com (8.11.6/8.11.6) with SMTP id h46Ipq317868 for ; Wed, 7 May 2003 00:21:52 +0530 Received: from 219.65.131.252 (SquirrelMail authenticated user alok.dube) by mail.apara.com with HTTP; Wed, 7 May 2003 00:21:52 +0530 (IST) References: <12f501c31360$c89dd180$1105f183@b90.tdd.sj.nec.com> <01e701c3139e$ce313e00$81c802c0@alok> <139a01c313f3$df429810$1105f183@b90.tdd.sj.nec.com> X-Priority: 3 Importance: Normal X-MSMail-Priority: Normal X-Mailer: SquirrelMail (version 1.2.6) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <1095.219.65.131.252.1052247112.squirrel@mail.apara.com> Date: Wed, 7 May 2003 00:21:52 +0530 Reply-To: Mailing List Sender: Mailing List From: Alok Dube Subject: Re: un-num p2p clarification. To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <139a01c313f3$df429810$1105f183@b90.tdd.sj.nec.com> Precedence: list Content-Transfer-Encoding: 8bit Hi, maybe im wrong.. ....doesnt it say somewhere in the RFC that the router-id is given a /32 address in OSPF? and propogated? -rgds Alok > Hi alok! > > To forward and process IP looks for valid IP address in the received > packet. Since in the case of un-num p2p, there is no specific IP > address in OSPF point of view, the Valid IP address of the other > interface, will be used as the source IP address in the IP Header. > > Btw: That's the reason OSPF specifies, to configure un-num p2p to an > interface of a router, the router should have atleast one valid IP > address (it may be for LAN or for loop-back). > > GKS. > ----- Original Message ----- > From: "alok" > To: > Sent: Tuesday, May 06, 2003 12:11 AM > Subject: Re: un-num p2p clarification. > > >> > Hi all, >> > >> > I have the following two doubts in Un-num p2p for OSPF. >> > >> > 1) If I bring up an un-num p2p with one of the other interface's >> > valid > ip >> > address (ex. LAN), does the un-num p2p need to be associated with >> > the > same >> > "AREA" with which the LAN has been associated??? or can be >> > associated > with >> > an different area address. >> > More clearly: The router R1 has three interfaces, but interface #1 >> > has a valid IP address and other two are un-num p2p interfaces. So, >> > the two >> un-num >> > p2p interfaces will use the Ip address of Interface #1. Assume, the >> > interface #1 got associated with Area 0. Now the question is, can >> > the >> un-num >> > p2p interfaces be associted to some other AREA other than AREA 0 or > not?? >> >> hi, >> >> pardon me if this has already been asked, >> >> can u please explain as to why they would use the "IP address" of > interface >> #1? >> >> wouldnt Link-id be "router-id"? >> >> -rgds >> Alok From owner-ospf@DISCUSS.MICROSOFT.COM Tue May 6 16:20:15 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07011 for ; Tue, 6 May 2003 16:20:14 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.009AE400@cherry.ease.lsoft.com>; Tue, 6 May 2003 16:23:09 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 715997 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 6 May 2003 16:23:08 -0400 Received: from 216.136.131.41 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 6 May 2003 16:23:08 -0400 Received: from [63.251.235.202] by web10905.mail.yahoo.com via HTTP; Tue, 06 May 2003 13:23:08 PDT MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20030506202308.91892.qmail@web10905.mail.yahoo.com> Date: Tue, 6 May 2003 13:23:08 -0700 Reply-To: Mailing List Sender: Mailing List From: j j Subject: Re: un-num p2p clarification. To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <12f501c31360$c89dd180$1105f183@b90.tdd.sj.nec.com> Precedence: list On Cisco routers I believe that your un-numbered interfaces will be in the same area as the interface from which the ip address is borrowed. If you don't want this then use a loopback interface. Your second question partly answers the first question. for the "network" command you have to use the ipaddress/mask of the interface from which you are borrowing. --- kamatchi soundaram wrote: > Hi all, > > I have the following two doubts in Un-num p2p for > OSPF. > > 1) If I bring up an un-num p2p with one of the other > interface's valid ip > address (ex. LAN), does the un-num p2p need to be > associated with the same > "AREA" with which the LAN has been associated??? or > can be associated with > an different area address. > More clearly: The router R1 has three interfaces, > but interface #1 has a > valid IP address and other two are un-num p2p > interfaces. So, the two un-num > p2p interfaces will use the Ip address of Interface > #1. Assume, the > interface #1 got associated with Area 0. Now the > question is, can the un-num > p2p interfaces be associted to some other AREA other > than AREA 0 or not?? > > 2) In implementation point of view: > Generally the numbered p2p and ethernet interfaces > will be configured as > Net-number/Mask and AREA. Since in numbered IP case, > each interface can be > specifically configured with Net num and mask and > AREA. > But in the case of un-num p2p, how the configuration > will be?? > For example what will be the net number and mask > and area configuation?? > > Thanks in advance, > GKS. __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com From owner-ospf@DISCUSS.MICROSOFT.COM Tue May 6 17:07:49 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09188 for ; Tue, 6 May 2003 17:07:48 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.009AE74D@cherry.ease.lsoft.com>; Tue, 6 May 2003 17:10:41 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 716065 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 6 May 2003 17:10:40 -0400 Received: from 192.25.240.36 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 6 May 2003 17:00:40 -0400 Received: from relcos2.cos.agilent.com (relcos2.cos.agilent.com [130.29.152.237]) by msgbas1x.cos.agilent.com (Postfix) with ESMTP id 114EA14A45 for ; Tue, 6 May 2003 15:00:40 -0600 (MDT) Received: from axcsbh2.cos.agilent.com (axcsbh2.cos.agilent.com [130.29.152.144]) by relcos2.cos.agilent.com (Postfix) with SMTP id D7C61646 for ; Tue, 6 May 2003 15:00:39 -0600 (MDT) Received: from 130.29.152.144 by axcsbh2.cos.agilent.com (InterScan E-Mail VirusWall NT); Tue, 06 May 2003 15:00:39 -0600 Received: by axcsbh2.cos.agilent.com with Internet Mail Service (5.5.2653.19) id <2ZGGG79F>; Tue, 6 May 2003 15:00:39 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Message-ID: <0D9185CE635BD511ACA50090277A6FCF037EA5C3@axcs18.cos.agilent.com> Date: Tue, 6 May 2003 15:00:38 -0600 Reply-To: Mailing List Sender: Mailing List From: Gail Browne Subject: Point to point destination address question To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi, Just a quick question, RFC2328 contradicts itself in describing destination addresses for OSPF pdu's on P2p networks, in section 8.1 reads "The IP destination address for the packet is selected as follows. On physical point-to-point networks, the IP destination is always set to the address AllSPFRouters. " but later in the sections on LSAcks and LSUpdates, it states that direct acks and retransmitted updates are always sent directly to the neighbor (unicast). My question is, which is correct, are they always multicast, or unicast for directs acks and retransmits, or is multicast directly to the neighbor anyway because a p2p network implies only 1 neighbor? Thanks, Gail From owner-ospf@DISCUSS.MICROSOFT.COM Tue May 6 19:10:34 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13585 for ; Tue, 6 May 2003 19:10:33 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.009AEB41@cherry.ease.lsoft.com>; Tue, 6 May 2003 19:13:27 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 716551 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 6 May 2003 19:13:27 -0400 Received: from 131.241.15.4 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 6 May 2003 19:13:26 -0400 Received: from netkeeper.sj.nec.com (netkeeper.sj.nec.com [131.241.31.2]) by mail4.nec.com (/) with ESMTP id h46NDODo007380 for ; Tue, 6 May 2003 16:13:24 -0700 (PDT) Received: from necsun.tdd.sj.nec.com (localhost [127.0.0.1]) by netkeeper.sj.nec.com (/) with ESMTP id h46NDIUM010724 for ; Tue, 6 May 2003 16:13:18 -0700 (PDT) Received: from bunny.tdd.sj.nec.com (bunny.tdd.sj.nec.com [131.241.9.33]) by necsun.tdd.sj.nec.com (8.12.8/8.12.8) with ESMTP id h46N2r3a027381 for ; Tue, 6 May 2003 16:02:53 -0700 (PDT) Received: from ems12 (ems12 [131.241.5.17]) by bunny.tdd.sj.nec.com with SMTP id h46N2qYS011192 for ; Tue, 6 May 2003 16:02:52 -0700 (PDT) References: <20030506202308.91892.qmail@web10905.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Message-ID: <13d401c31426$05a925f0$1105f183@b90.tdd.sj.nec.com> Date: Tue, 6 May 2003 16:20:02 -0700 Reply-To: Mailing List Sender: Mailing List From: kamatchi soundaram Subject: Re: un-num p2p clarification. To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Yes! by looking at the CISCO routers, i do believe that un-numbered interfaces will be in the same area as the interface from which IP address is borrowes. But my question is why can't use different area address for the un-numbered interfaces even though the IP address is borrowed from the other interface and not from the Loop back interface?? GKS. ----- Original Message ----- From: "j j" To: Sent: Tuesday, May 06, 2003 1:23 PM Subject: Re: un-num p2p clarification. > On Cisco routers I believe that your un-numbered > interfaces will be in the same area as the interface > from which the ip address is borrowed. If you > don't want this then use a loopback interface. > > Your second question partly answers the first > question. > for the "network" command you have to use the > ipaddress/mask of the interface from which you are > borrowing. > > > --- kamatchi soundaram > wrote: > > Hi all, > > > > I have the following two doubts in Un-num p2p for > > OSPF. > > > > 1) If I bring up an un-num p2p with one of the other > > interface's valid ip > > address (ex. LAN), does the un-num p2p need to be > > associated with the same > > "AREA" with which the LAN has been associated??? or > > can be associated with > > an different area address. > > More clearly: The router R1 has three interfaces, > > but interface #1 has a > > valid IP address and other two are un-num p2p > > interfaces. So, the two un-num > > p2p interfaces will use the Ip address of Interface > > #1. Assume, the > > interface #1 got associated with Area 0. Now the > > question is, can the un-num > > p2p interfaces be associted to some other AREA other > > than AREA 0 or not?? > > > > 2) In implementation point of view: > > Generally the numbered p2p and ethernet interfaces > > will be configured as > > Net-number/Mask and AREA. Since in numbered IP case, > > each interface can be > > specifically configured with Net num and mask and > > AREA. > > But in the case of un-num p2p, how the configuration > > will be?? > > For example what will be the net number and mask > > and area configuation?? > > > > Thanks in advance, > > GKS. > > > __________________________________ > Do you Yahoo!? > The New Yahoo! Search - Faster. Easier. Bingo. > http://search.yahoo.com > From owner-ospf@DISCUSS.MICROSOFT.COM Tue May 6 20:21:17 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15175 for ; Tue, 6 May 2003 20:21:17 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.009AEE69@cherry.ease.lsoft.com>; Tue, 6 May 2003 20:24:13 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 716915 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 6 May 2003 20:24:12 -0400 Received: from 216.136.131.43 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 6 May 2003 20:24:12 -0400 Received: from [63.251.235.202] by web10907.mail.yahoo.com via HTTP; Tue, 06 May 2003 17:24:11 PDT MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20030507002411.90938.qmail@web10907.mail.yahoo.com> Date: Tue, 6 May 2003 17:24:11 -0700 Reply-To: Mailing List Sender: Mailing List From: j j Subject: Re: un-num p2p clarification. To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <13d401c31426$05a925f0$1105f183@b90.tdd.sj.nec.com> Precedence: list Its not clear to me why. But their config commands definitely does not support this. for e.g. - interface ethernet 0 ip address 10.1.1.1 255.255.255.0 interface serial 0 ip unnumbered interface ethernet 0 router ospf 99 network 10.1.1.0 0.0.0.255 area 2 So both ethernet and serial interface would fall under area 2. It is not clear to me why it would not be possible to have a command under interface to specify an ospf area. Do you have a good reason to not use a loopback interface? --- kamatchi soundaram wrote: > Yes! by looking at the CISCO routers, i do believe > that un-numbered > interfaces will be in the same area as the interface > from which IP address > is borrowes. But my question is why can't use > different area address for the > un-numbered interfaces even though the IP address is > borrowed from the other > interface and not from the Loop back interface?? > > GKS. > ----- Original Message ----- > From: "j j" > To: > Sent: Tuesday, May 06, 2003 1:23 PM > Subject: Re: un-num p2p clarification. > > > > On Cisco routers I believe that your un-numbered > > interfaces will be in the same area as the > interface > > from which the ip address is borrowed. If you > > don't want this then use a loopback interface. > > > > Your second question partly answers the first > > question. > > for the "network" command you have to use the > > ipaddress/mask of the interface from which you are > > borrowing. > > > > > > --- kamatchi soundaram > > wrote: > > > Hi all, > > > > > > I have the following two doubts in Un-num p2p > for > > > OSPF. > > > > > > 1) If I bring up an un-num p2p with one of the > other > > > interface's valid ip > > > address (ex. LAN), does the un-num p2p need to > be > > > associated with the same > > > "AREA" with which the LAN has been associated??? > or > > > can be associated with > > > an different area address. > > > More clearly: The router R1 has three > interfaces, > > > but interface #1 has a > > > valid IP address and other two are un-num p2p > > > interfaces. So, the two un-num > > > p2p interfaces will use the Ip address of > Interface > > > #1. Assume, the > > > interface #1 got associated with Area 0. Now the > > > question is, can the un-num > > > p2p interfaces be associted to some other AREA > other > > > than AREA 0 or not?? > > > > > > 2) In implementation point of view: > > > Generally the numbered p2p and ethernet > interfaces > > > will be configured as > > > Net-number/Mask and AREA. Since in numbered IP > case, > > > each interface can be > > > specifically configured with Net num and mask > and > > > AREA. > > > But in the case of un-num p2p, how the > configuration > > > will be?? > > > For example what will be the net number and > mask > > > and area configuation?? > > > > > > Thanks in advance, > > > GKS. > > > > > > __________________________________ > > Do you Yahoo!? > > The New Yahoo! Search - Faster. Easier. Bingo. > > http://search.yahoo.com > > __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com From owner-ospf@DISCUSS.MICROSOFT.COM Tue May 6 21:40:09 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16955 for ; Tue, 6 May 2003 21:40:08 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.009AEFFC@cherry.ease.lsoft.com>; Tue, 6 May 2003 21:43:04 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 717088 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 6 May 2003 21:43:04 -0400 Received: from 156.147.1.151 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 6 May 2003 21:43:03 -0400 Received: from [150.150.40.133] (yjim@lge.com) by mail1.lge.co.kr (Terrace Internet Messaging Server) with ESMTP id 2003050710:35:46:073837.337.25 for ; Wed, 07 May 2003 10:35:45 +0900 (KST) References: <0D9185CE635BD511ACA50090277A6FCF037EA5C3@axcs18.cos.agilent.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Message-ID: <017501c31439$ff7a6a90$85289696@yongjuni> Date: Wed, 7 May 2003 10:43:02 +0900 Reply-To: Mailing List Sender: Mailing List From: Yongjun Im Subject: Re: Point to point destination address question Comments: cc: ??? To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id VAA16955 I remember we faced some interoperability problem since one box was sending LSUpdate (NOT retransmit) with a unicast address on a ptp interface, while its neighbor was expecting LSUpdate with a multicast address. Hence they couldn't exchange LSUpdates even though they made adjacencies using HELLO(multicast). I believe the specification on a unicast or multicast address on the ptp interface should be clarified by using expression such as MUST, SHOULD or something. ----- Original Message ----- From: "Mailing List" To: Sent: Wednesday, May 07, 2003 6:00 AM Subject: Point to point destination address question > Hi, > > Just a quick question, RFC2328 contradicts itself in describing destination addresses for OSPF pdu's on P2p networks, in section 8.1 reads > "The IP destination address for the packet is selected as > follows. On physical point-to-point networks, the IP > destination is always set to the address AllSPFRouters. " > but later in the sections on LSAcks and LSUpdates, it states that direct acks and retransmitted updates are always sent directly to the neighbor (unicast). My question is, which is correct, are they always multicast, or unicast for directs acks and retransmits, or is multicast directly to the neighbor anyway because a p2p network implies only 1 neighbor? > > Thanks, > Gail > > From owner-ospf@DISCUSS.MICROSOFT.COM Wed May 7 11:46:01 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06262 for ; Wed, 7 May 2003 11:46:01 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.009B050A@cherry.ease.lsoft.com>; Wed, 7 May 2003 11:48:32 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 719283 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 7 May 2003 11:48:32 -0400 Received: from 216.136.131.44 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 7 May 2003 11:48:31 -0400 Received: from [209.179.217.163] by web10908.mail.yahoo.com via HTTP; Wed, 07 May 2003 08:48:30 PDT MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20030507154830.1358.qmail@web10908.mail.yahoo.com> Date: Wed, 7 May 2003 08:48:30 -0700 Reply-To: Mailing List Sender: Mailing List From: j j Subject: Re: Point to point destination address question To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <017501c31439$ff7a6a90$85289696@yongjuni> Precedence: list An OSPF implementation shouldn't be written to have these checks (multicast or unicast). This is done at lower layers (ip and below in case of multicast). As long as the pkt is "destined to us", ip layer will accept it and pass it to the right application. my 2 cents. --- Yongjun Im wrote: > I remember we faced some interoperability problem > since > one box was sending LSUpdate (NOT retransmit) with a > unicast address > on a ptp interface, while its neighbor was expecting > LSUpdate with a multicast address. > Hence they couldn't exchange LSUpdates even though > they made adjacencies > using HELLO(multicast). I believe the specification > on a unicast or multicast address on the > ptp interface should be clarified by using > expression such as MUST, SHOULD or something. > > ----- Original Message ----- > From: "Mailing List" > To: > Sent: Wednesday, May 07, 2003 6:00 AM > Subject: Point to point destination address question > > > > Hi, > > > > Just a quick question, RFC2328 contradicts itself > in describing destination addresses for OSPF pdu's > on P2p networks, in section 8.1 reads > > "The IP destination address for the packet is > selected as > > follows. On physical point-to-point > networks, the IP > > destination is always set to the address > AllSPFRouters. " > > but later in the sections on LSAcks and LSUpdates, > it states that direct acks and retransmitted updates > are always sent directly to the neighbor (unicast). > My question is, which is correct, are they always > multicast, or unicast for directs acks and > retransmits, or is multicast directly to the > neighbor anyway because a p2p network implies only 1 > neighbor? > > > > Thanks, > > Gail > > > > __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com From owner-ospf@DISCUSS.MICROSOFT.COM Thu May 8 12:47:36 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29745 for ; Thu, 8 May 2003 12:47:35 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.009B2A43@cherry.ease.lsoft.com>; Thu, 8 May 2003 12:50:31 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 722760 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 8 May 2003 12:50:30 -0400 Received: from 64.60.75.69 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 8 May 2003 12:50:30 -0400 Received: by racerx.ixiacom.com with Internet Mail Service (5.5.2653.19) id ; Thu, 8 May 2003 09:39:38 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <15FDCE057B48784C80836803AE3598D52930A3@racerx.ixiacom.com> Date: Thu, 8 May 2003 09:39:37 -0700 Reply-To: Mailing List Sender: Mailing List From: Ankur Sheth Subject: Intra-Area-Prefix LSA & duplicate prefixes To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Say a router R1 has two Interfaces (both links to transit networks) and it is fully adjacent with another router on interface I1 but has not established any adjacency on I2. Also let's assume that I2 has two global IPv6 addresses 2001::1/64 and 2001::2a0:a5ff:fe12:615a/64. Now when R1 is building an Intra-Area-Prefix LSA (which references it's own Router LSA) does it include the prefix 3000::/64 twice? Section 3.4.3.7 of RFC 2740 pages 32-34 indicates that when a DR is building an Intra-Area-Prefix LSA (referencing the Network LSA) it does checking for duplicate prefixes, but does not say the same when you're building an Intra-Area-Prefix LSA referencing your Router LSA? Should the checking for duplicate prefixes be done here as well? thanks, Ankur From owner-ospf@DISCUSS.MICROSOFT.COM Fri May 9 04:05:04 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08579 for ; Fri, 9 May 2003 04:05:04 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.009B4563@cherry.ease.lsoft.com>; Fri, 9 May 2003 4:07:57 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 725332 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 9 May 2003 04:07:57 -0400 Received: from 203.178.143.91 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 9 May 2003 04:07:56 -0400 Received: from localhost (localhost [127.0.0.1]) by plant.sfc.wide.ad.jp (Postfix) with ESMTP id D24672E86E; Fri, 9 May 2003 17:07:54 +0900 (JST) References: <15FDCE057B48784C80836803AE3598D52930A3@racerx.ixiacom.com> X-Mailer: Mew version 3.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20030509.170754.128595721.yasu@sfc.wide.ad.jp> Date: Fri, 9 May 2003 17:07:54 +0900 Reply-To: Mailing List Sender: Mailing List From: Yasuhiro Ohara Subject: Re: Intra-Area-Prefix LSA & duplicate prefixes Comments: To: asheth@IXIACOM.COM To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <15FDCE057B48784C80836803AE3598D52930A3@racerx.ixiacom.com> Precedence: list Content-Transfer-Encoding: 7bit Hi. I guess, we should. We should avoid the redundant prefix in originating stub Intra-Prefix-LSA, as well as transit Intra-Prefix-LSA. Originating the same prefix in a LSA is no more than just consuming redundant bandwidth, though in this case OSPFv3 still works with having duplicated prefixes unified during calculation of the LSA on receiving routers. Originating the same prefix in multiple LSAs (and how to avoid it) is another issue. RFC 2740 does not specify the case, and I believe most implementation will originate them as is (with having duplicated prefixes included). Assigning the same prefix to multiple link (i.e. duplicated) can be considered configuration mistake. In this case hosts wishes to speak to the prefix reaches different link, according to the place the host exists. Hope this helps. regards, yasu From: Ankur Sheth Subject: Intra-Area-Prefix LSA & duplicate prefixes Date: Thu, 8 May 2003 09:39:37 -0700 > Say a router R1 has two Interfaces (both links to transit networks) and it > is fully adjacent with another router on interface I1 but has not > established any adjacency on I2. Also let's assume that I2 has two global > IPv6 addresses 2001::1/64 and 2001::2a0:a5ff:fe12:615a/64. > > Now when R1 is building an Intra-Area-Prefix LSA (which references it's own > Router LSA) does it include the prefix 3000::/64 twice? Section 3.4.3.7 of > RFC 2740 pages 32-34 indicates that when a DR is building an > Intra-Area-Prefix LSA (referencing the Network LSA) it does checking for > duplicate prefixes, but does not say the same when you're building an > Intra-Area-Prefix LSA referencing your Router LSA? Should the checking for > duplicate prefixes be done here as well? > > thanks, > Ankur From owner-ospf@DISCUSS.MICROSOFT.COM Sun May 11 14:24:06 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09475 for ; Sun, 11 May 2003 14:24:06 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.009B9933@cherry.ease.lsoft.com>; 11 May 2003 14:27:03 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 732589 for OSPF@DISCUSS.MICROSOFT.COM; Sun, 11 May 2003 14:27:02 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 11 May 2003 14:27:02 -0400 Received: from redback.com (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id 5D7514A3E28 for ; Sun, 11 May 2003 11:27:01 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <12f501c31360$c89dd180$1105f183@b90.tdd.sj.nec.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3EBE960D.2000604@redback.com> Date: Sun, 11 May 2003 14:27:25 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: un-num p2p clarification. To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit kamatchi soundaram wrote: > Hi all, > > I have the following two doubts in Un-num p2p for OSPF. > > 1) If I bring up an un-num p2p with one of the other interface's valid ip > address (ex. LAN), does the un-num p2p need to be associated with the same > "AREA" with which the LAN has been associated??? or can be associated with > an different area address. > More clearly: The router R1 has three interfaces, but interface #1 has a > valid IP address and other two are un-num p2p interfaces. So, the two un-num > p2p interfaces will use the Ip address of Interface #1. Assume, the > interface #1 got associated with Area 0. Now the question is, can the un-num > p2p interfaces be associted to some other AREA other than AREA 0 or not?? There is no protocol requirement for the two interfaces to be in the same area or for the P2P link's reference interface to be advertised at all. > > 2) In implementation point of view: > Generally the numbered p2p and ethernet interfaces will be configured as > Net-number/Mask and AREA. Since in numbered IP case, each interface can be > specifically configured with Net num and mask and AREA. > But in the case of un-num p2p, how the configuration will be?? > For example what will be the net number and mask and area configuation?? You are confusing a specific vendor's implementation with the OSPF specification. Read RFC 2328 Appendix C. > > Thanks in advance, > GKS. > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Sun May 11 16:11:12 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12069 for ; Sun, 11 May 2003 16:11:12 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.009B9AE4@cherry.ease.lsoft.com>; 11 May 2003 16:14:11 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 732753 for OSPF@DISCUSS.MICROSOFT.COM; Sun, 11 May 2003 16:14:10 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 11 May 2003 16:14:10 -0400 Received: from redback.com (login003.redback.com [155.53.12.55]) by prattle.redback.com (Postfix) with ESMTP id A81A794B9D9 for ; Sun, 11 May 2003 13:14:09 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <0D9185CE635BD511ACA50090277A6FCF037EA5C3@axcs18.cos.agilent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3EBEAF28.6010406@redback.com> Date: Sun, 11 May 2003 16:14:32 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Point to point destination address question To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Gail, See below. Gail Browne wrote: > Hi, > > Just a quick question, RFC2328 contradicts itself in describing destination addresses for OSPF pdu's on P2p networks, in section 8.1 reads > "The IP destination address for the packet is selected as > follows. On physical point-to-point networks, the IP > destination is always set to the address AllSPFRouters. " This is exactly what should be done. > but later in the sections on LSAcks and LSUpdates, it states that direct acks and retransmitted updates are always sent > directly to the neighbor (unicast). My question is, which is correct, are they always multicast, or unicast for directs > acks and retransmits, or is multicast directly to the neighbor anyway because a p2p network implies only 1 neighbor? It does not say this. It says: " On non-broadcast networks, separate Link State Update packets must be sent, as unicasts, to each adjacent neighbor (i.e., those in state Exchange or greater). The destination IP addresses for these packets are the neighbors' IP addresses." Non-broadcast networks include NBMA and P2MP networks - not P2P. Refer to the defintions in section 1.2. > Thanks, > Gail > P.S. In the future, please put \nl characters in your posts to this list. Thanks, Acee -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Tue May 13 06:54:36 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03345 for ; Tue, 13 May 2003 06:54:36 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.009BDE82@cherry.ease.lsoft.com>; Tue, 13 May 2003 6:57:35 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 665502 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 13 May 2003 06:57:35 -0400 Received: from 209.119.0.100 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 13 May 2003 06:57:35 -0400 Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.009BDE58@cherry.ease.lsoft.com>; Tue, 13 May 2003 6:57:35 -0400 Message-ID: Date: Tue, 13 May 2003 06:57:34 -0400 Reply-To: Mailing List Sender: Mailing List From: Dror Subject: DR election To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi, I have a question regarding a DR election algorithm. If I have a netowrk with 3 routers R1,-R3, each having the same priority and with router IDs 0.0.0.1, 0.0.0.2, 0.0.0.3 respectively. After a DR election process is done, R3 will be DR, R2 will be BDR and R1 will be DR-Other. This is the result of the DR election process since R3 has the largest router ID. If I add a new router R4 with router ID 0.0.0.4, do I expect R4 to become the DR, or does it just become another DR-other since there is already a DR in the network. Does the result depend on whether R4 is connected to the network when it is still in the WAIT state, or the result is the same nevertheless. Thanks Dror From owner-ospf@DISCUSS.MICROSOFT.COM Tue May 13 07:39:28 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04485 for ; Tue, 13 May 2003 07:39:28 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.009BDD60@cherry.ease.lsoft.com>; Tue, 13 May 2003 7:42:29 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 665587 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 13 May 2003 07:42:28 -0400 Received: from 209.119.0.100 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 13 May 2003 07:42:28 -0400 Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.009BDED2@cherry.ease.lsoft.com>; Tue, 13 May 2003 7:42:28 -0400 Message-ID: Date: Tue, 13 May 2003 07:42:28 -0400 Reply-To: Mailing List Sender: Mailing List From: Igor Miroshnik Subject: Re: DR election To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list On Tue, 13 May 2003 06:57:34 -0400, Dror wrote: >Hi, > >I have a question regarding a DR election algorithm. If I have a netowrk >with 3 routers R1,-R3, each having the same priority and with router IDs >0.0.0.1, 0.0.0.2, 0.0.0.3 respectively. > >After a DR election process is done, R3 will be DR, R2 will be BDR and R1 >will be DR-Other. This is the result of the DR election process since R3 >has the largest router ID. > >If I add a new router R4 with router ID 0.0.0.4, do I expect R4 to become >the DR, or does it just become another DR-other since there is already a DR >in the network. > >Does the result depend on whether R4 is connected to the network when it is >still in the WAIT state, or the result is the same nevertheless. > >Thanks >Dror In case of DR/BDR having already been elected, no new DR/BDR election will ensue, since only R3 lists itself as DR, and only R2 lists itself as BDR. R4 will analyze the BDR-candidate list of a single member (R2), and one for DR (listing merely R3). As there is no choice, R4 will agree upon the existing DR/BDR. On the other hand, if none of the routers declares itself DR/BDR yet, R4 will run its own candidature, and take on the job. From owner-ospf@DISCUSS.MICROSOFT.COM Tue May 13 07:52:33 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04733 for ; Tue, 13 May 2003 07:52:33 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.009BDF86@cherry.ease.lsoft.com>; Tue, 13 May 2003 7:55:34 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 665663 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 13 May 2003 07:55:34 -0400 Received: from 64.102.124.12 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 13 May 2003 07:55:34 -0400 Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h4DBtLmu014983 for ; Tue, 13 May 2003 07:55:27 -0400 (EDT) Received: from dhcp-64-102-48-215.cisco.com (dhcp-64-102-48-215.cisco.com [64.102.48.215]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id HAA06819 for ; Tue, 13 May 2003 07:55:21 -0400 (EDT) References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Tue, 13 May 2003 07:55:39 -0400 Reply-To: Mailing List Sender: Mailing List From: Russ White Subject: Re: DR election To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Precedence: list As long as there is already a dr on the link, R4 would not take over as the DR. Or it shouldn't. Think of it this way: The DR isn't elected first, the BDR is. Then the routers attached to the link "discover" there is no DR, and promote the BDR to DR, and elect a new BDR. :-) Russ On Tue, 13 May 2003, Dror wrote: > Hi, > > I have a question regarding a DR election algorithm. If I have a netowrk > with 3 routers R1,-R3, each having the same priority and with router IDs > 0.0.0.1, 0.0.0.2, 0.0.0.3 respectively. > > After a DR election process is done, R3 will be DR, R2 will be BDR and R1 > will be DR-Other. This is the result of the DR election process since R3 > has the largest router ID. > > If I add a new router R4 with router ID 0.0.0.4, do I expect R4 to become > the DR, or does it just become another DR-other since there is already a DR > in the network. > > Does the result depend on whether R4 is connected to the network when it is > still in the WAIT state, or the result is the same nevertheless. > > Thanks > Dror > __________________________________ riw@cisco.com CCIE <>< Grace Alone From owner-ospf@DISCUSS.MICROSOFT.COM Tue May 13 08:00:51 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05404 for ; Tue, 13 May 2003 08:00:51 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.009BDEDD@cherry.ease.lsoft.com>; Tue, 13 May 2003 8:03:51 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 665753 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 13 May 2003 08:03:51 -0400 Received: from 198.152.13.101 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 13 May 2003 08:03:51 -0400 Received: from ierw.net.avaya.com (localhost [127.0.0.1]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id IAA13132 for ; Tue, 13 May 2003 08:01:10 -0400 (EDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id IAA13101 for ; Tue, 13 May 2003 08:01:09 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: DR election Thread-Index: AcMZRpJ6jri/n7mWRsaQ5+5GdIKdkwAAO1WA Message-ID: Date: Tue, 13 May 2003 15:03:48 +0300 Reply-To: Mailing List Sender: Mailing List From: "Zebaida, Dror (Dror)" Subject: Re: DR election To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA05404 I understand that if there is already a DR/BDR then R4 will not become the DR. However, when an interface transitions out of the WAIT state, if it thinks it is alone on the network, it declares itself the DR. If after that, it connects to the network, there are 2 routers declaring themselves DR. In our case R3 and R4. At this stage, is a new DR elected, or does R3 remain the DR. The scenario I am describing is R4 is conneced to the network after it transitioned out of the WAIT state (after 40 seconds) Thanks -----Original Message----- From: Russ White [mailto:ruwhite@CISCO.COM] Sent: Tuesday, May 13, 2003 2:56 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: DR election As long as there is already a dr on the link, R4 would not take over as the DR. Or it shouldn't. Think of it this way: The DR isn't elected first, the BDR is. Then the routers attached to the link "discover" there is no DR, and promote the BDR to DR, and elect a new BDR. :-) Russ On Tue, 13 May 2003, Dror wrote: > Hi, > > I have a question regarding a DR election algorithm. If I have a netowrk > with 3 routers R1,-R3, each having the same priority and with router IDs > 0.0.0.1, 0.0.0.2, 0.0.0.3 respectively. > > After a DR election process is done, R3 will be DR, R2 will be BDR and R1 > will be DR-Other. This is the result of the DR election process since R3 > has the largest router ID. > > If I add a new router R4 with router ID 0.0.0.4, do I expect R4 to become > the DR, or does it just become another DR-other since there is already a DR > in the network. > > Does the result depend on whether R4 is connected to the network when it is > still in the WAIT state, or the result is the same nevertheless. > > Thanks > Dror > __________________________________ riw@cisco.com CCIE <>< Grace Alone From owner-ospf@DISCUSS.MICROSOFT.COM Tue May 13 09:25:07 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11193 for ; Tue, 13 May 2003 09:25:06 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.009BDFD1@cherry.ease.lsoft.com>; Tue, 13 May 2003 9:28:07 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 665984 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 13 May 2003 09:28:07 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 13 May 2003 09:28:06 -0400 Received: from redback.com (login003.redback.com [155.53.12.55]) by prattle.redback.com (Postfix) with ESMTP id A35A085BD80 for ; Tue, 13 May 2003 06:28:05 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3EC0F2E5.5020507@redback.com> Date: Tue, 13 May 2003 09:28:05 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: DR election To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi Dror, Zebaida, Dror (Dror) wrote: > I understand that if there is already a DR/BDR then R4 will not become the DR. As described succintly in Russ White's e-mail below. > However, when an interface transitions out of the WAIT state, if it thinks it is > alone on the network, it declares itself the DR. If after that, it connects to the > network, there are 2 routers declaring themselves DR. In our case R3 and R4. > At this stage, is a new DR elected, or does R3 remain the DR. > > The scenario I am describing is R4 is conneced to the network after it transitioned > out of the WAIT state (after 40 seconds) This really should never happen on a broadcast or NBMA network unless you have some type of connectivity or an NBMA configuration problem. I have seen it happen on an NBMA network if the existing DR and BDR are using the RFC 2328 appendix C suggested X.25 poll interval of 2 minutes and all the DR eligible neighbors are not configured as eligible on all the DR eligible routers. When it happens a new DR election will be triggered and R4 will become DR. I believe R2 will remain as BDR. Thanks, Acee > > Thanks > > > > -----Original Message----- > From: Russ White [mailto:ruwhite@CISCO.COM] > Sent: Tuesday, May 13, 2003 2:56 PM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Re: DR election > > > As long as there is already a dr on the link, R4 would not take over as the > DR. Or it shouldn't. Think of it this way: The DR isn't elected first, the > BDR is. Then the routers attached to the link "discover" there is no DR, > and promote the BDR to DR, and elect a new BDR. > > :-) > > Russ > > On Tue, 13 May 2003, Dror wrote: > > >>Hi, >> >>I have a question regarding a DR election algorithm. If I have a netowrk >>with 3 routers R1,-R3, each having the same priority and with router IDs >>0.0.0.1, 0.0.0.2, 0.0.0.3 respectively. >> >>After a DR election process is done, R3 will be DR, R2 will be BDR and R1 >>will be DR-Other. This is the result of the DR election process since R3 >>has the largest router ID. >> >>If I add a new router R4 with router ID 0.0.0.4, do I expect R4 to become >>the DR, or does it just become another DR-other since there is already a DR >>in the network. >> >>Does the result depend on whether R4 is connected to the network when it is >>still in the WAIT state, or the result is the same nevertheless. >> >>Thanks >>Dror >> > > > __________________________________ > riw@cisco.com CCIE <>< Grace Alone > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Tue May 13 09:36:13 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11664 for ; Tue, 13 May 2003 09:36:13 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.009BE040@cherry.ease.lsoft.com>; Tue, 13 May 2003 9:39:15 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 666002 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 13 May 2003 09:39:15 -0400 Received: from 65.244.18.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 13 May 2003 09:29:15 -0400 Received: from avianserver.aviancommunications.com by blackhole.proquent.com via smtpd (for discuss.microsoft.com [209.119.0.18]) with ESMTP; Tue, 13 May 2003 09:30:26 -0400 Received: from guinness.aviancommunications.com ([192.168.18.11]) by AVIANSERVER.aviancommunications.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 13 May 2003 09:29:23 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: DR election Thread-Index: AcMZRpJ6jri/n7mWRsaQ5+5GdIKdkwAAO1WAAAJ8BsA= X-OriginalArrivalTime: 13 May 2003 13:29:23.0381 (UTC) FILETIME=[AABA1E50:01C31953] Message-ID: <249ED70AF90130429A83AA992183BF5D6A7B3B@guinness.aviancommunications.com> Date: Tue, 13 May 2003 09:29:24 -0400 Reply-To: Mailing List Sender: Mailing List From: Phil Chen Subject: Re: DR election To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA11664 If I understand you correctly, you are talking about a situation where a IP subnetwork is partitioned (may be due to some layer 2 problems) where each partition may have tis own DR/BDR. In this case, when partitions are merged, R4 will be the new DR for the final healed IP subnetwork. R3 will become DR-other. R2 remains as BDR (unless there is another BDR from other partition). --Phil -----Original Message----- From: Zebaida, Dror (Dror) [mailto:dzebaida@AVAYA.COM] Sent: Tuesday, May 13, 2003 8:04 AM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: DR election I understand that if there is already a DR/BDR then R4 will not become the DR. However, when an interface transitions out of the WAIT state, if it thinks it is alone on the network, it declares itself the DR. If after that, it connects to the network, there are 2 routers declaring themselves DR. In our case R3 and R4. At this stage, is a new DR elected, or does R3 remain the DR. The scenario I am describing is R4 is conneced to the network after it transitioned out of the WAIT state (after 40 seconds) Thanks -----Original Message----- From: Russ White [mailto:ruwhite@CISCO.COM] Sent: Tuesday, May 13, 2003 2:56 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: DR election As long as there is already a dr on the link, R4 would not take over as the DR. Or it shouldn't. Think of it this way: The DR isn't elected first, the BDR is. Then the routers attached to the link "discover" there is no DR, and promote the BDR to DR, and elect a new BDR. :-) Russ On Tue, 13 May 2003, Dror wrote: > Hi, > > I have a question regarding a DR election algorithm. If I have a netowrk > with 3 routers R1,-R3, each having the same priority and with router IDs > 0.0.0.1, 0.0.0.2, 0.0.0.3 respectively. > > After a DR election process is done, R3 will be DR, R2 will be BDR and R1 > will be DR-Other. This is the result of the DR election process since R3 > has the largest router ID. > > If I add a new router R4 with router ID 0.0.0.4, do I expect R4 to become > the DR, or does it just become another DR-other since there is already a DR > in the network. > > Does the result depend on whether R4 is connected to the network when it is > still in the WAIT state, or the result is the same nevertheless. > > Thanks > Dror > __________________________________ riw@cisco.com CCIE <>< Grace Alone From owner-ospf@DISCUSS.MICROSOFT.COM Tue May 13 09:43:09 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11845 for ; Tue, 13 May 2003 09:43:09 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.009BE0E1@cherry.ease.lsoft.com>; Tue, 13 May 2003 9:46:11 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 666031 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 13 May 2003 09:46:10 -0400 Received: from 198.152.12.101 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 13 May 2003 09:46:10 -0400 Received: from iere.net.avaya.com (localhost [127.0.0.1]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id h4DDh6x27620 for ; Tue, 13 May 2003 09:43:06 -0400 (EDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id h4DDh5h27600 for ; Tue, 13 May 2003 09:43:05 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: DR election Thread-Index: AcMZRpJ6jri/n7mWRsaQ5+5GdIKdkwAAO1WAAAJ8BsAAAPuf4A== Message-ID: Date: Tue, 13 May 2003 16:46:08 +0300 Reply-To: Mailing List Sender: Mailing List From: "Zebaida, Dror (Dror)" Subject: Re: DR election To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA11845 Hi Phil, I don't mean exactly a partitioned network. This is what I mean: 1) R1 -------------------R2 | | N10 | R3 2) All connected and R3 is elected to be the DR since it has the highest router ID. 3) R4 is configured to run ospf on an interface belonging to N10. However it is not physically connecet to N10 4) R4 is transitioned out of it WAIT state after 40 seconds thinking it's alone on N10 (not receiving any HELLOS) 5) R4 is physically connected to N10 6) R1/R2/R3 all send HELLOS with R3 DR and R2 BDR. R4 sends HELLO with R4 DR 7) what happens now??? R3 remains DR or R4 is selected to be DR. Hope this is clear Thanks Dror -----Original Message----- From: Phil Chen [mailto:pchen@PROQUENT.COM] Sent: Tuesday, May 13, 2003 4:29 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: DR election If I understand you correctly, you are talking about a situation where a IP subnetwork is partitioned (may be due to some layer 2 problems) where each partition may have tis own DR/BDR. In this case, when partitions are merged, R4 will be the new DR for the final healed IP subnetwork. R3 will become DR-other. R2 remains as BDR (unless there is another BDR from other partition). --Phil -----Original Message----- From: Zebaida, Dror (Dror) [mailto:dzebaida@AVAYA.COM] Sent: Tuesday, May 13, 2003 8:04 AM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: DR election I understand that if there is already a DR/BDR then R4 will not become the DR. However, when an interface transitions out of the WAIT state, if it thinks it is alone on the network, it declares itself the DR. If after that, it connects to the network, there are 2 routers declaring themselves DR. In our case R3 and R4. At this stage, is a new DR elected, or does R3 remain the DR. The scenario I am describing is R4 is conneced to the network after it transitioned out of the WAIT state (after 40 seconds) Thanks -----Original Message----- From: Russ White [mailto:ruwhite@CISCO.COM] Sent: Tuesday, May 13, 2003 2:56 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: DR election As long as there is already a dr on the link, R4 would not take over as the DR. Or it shouldn't. Think of it this way: The DR isn't elected first, the BDR is. Then the routers attached to the link "discover" there is no DR, and promote the BDR to DR, and elect a new BDR. :-) Russ On Tue, 13 May 2003, Dror wrote: > Hi, > > I have a question regarding a DR election algorithm. If I have a netowrk > with 3 routers R1,-R3, each having the same priority and with router IDs > 0.0.0.1, 0.0.0.2, 0.0.0.3 respectively. > > After a DR election process is done, R3 will be DR, R2 will be BDR and R1 > will be DR-Other. This is the result of the DR election process since R3 > has the largest router ID. > > If I add a new router R4 with router ID 0.0.0.4, do I expect R4 to become > the DR, or does it just become another DR-other since there is already a DR > in the network. > > Does the result depend on whether R4 is connected to the network when it is > still in the WAIT state, or the result is the same nevertheless. > > Thanks > Dror > __________________________________ riw@cisco.com CCIE <>< Grace Alone From owner-ospf@DISCUSS.MICROSOFT.COM Tue May 13 10:09:50 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13452 for ; Tue, 13 May 2003 10:09:48 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.009BE1D3@cherry.ease.lsoft.com>; Tue, 13 May 2003 10:12:49 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 666115 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 13 May 2003 10:12:49 -0400 Received: from 203.199.83.26 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 13 May 2003 10:12:49 -0400 Received: (qmail 19999 invoked by uid 510); 13 May 2003 14:12:44 -0000 Received: from unknown (203.197.138.201) by rediffmail.com via HTTP; 13 may 2003 14:12:44 -0000 MIME-Version: 1.0 Content-type: text/plain; format=flowed Content-Disposition: inline Message-ID: <20030513141244.19998.qmail@webmail16.rediffmail.com> Date: Tue, 13 May 2003 14:12:44 -0000 Reply-To: Mailing List Sender: Mailing List From: Vivek Dubey Subject: Re: DR election To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list As Acee pointed out R4 will become the DR and there is no change for BDR. Have seen the scenario you described below while experimenting !!!! On Tue, 13 May 2003 Zebaida, Dror (Dror) wrote : >Hi Phil, > >I don't mean exactly a partitioned network. This is what I >mean: > >1) R1 -------------------R2 > | > | N10 > | > R3 > >2) All connected and R3 is elected to be the DR since it has the >highest router ID. > >3) R4 is configured to run ospf on an interface belonging to N10. >However it is not physically connecet to N10 > >4) R4 is transitioned out of it WAIT state after 40 seconds >thinking it's alone on N10 (not receiving any HELLOS) > >5) R4 is physically connected to N10 > >6) R1/R2/R3 all send HELLOS with R3 DR and R2 BDR. R4 sends >HELLO with R4 DR > >7) what happens now??? R3 remains DR or R4 is selected >to be DR. > > >Hope this is clear >Thanks >Dror > > > > > > >-----Original Message----- > From: Phil Chen [mailto:pchen@PROQUENT.COM] >Sent: Tuesday, May 13, 2003 4:29 PM >To: OSPF@DISCUSS.MICROSOFT.COM >Subject: Re: DR election > > >If I understand you correctly, you are talking about a situation >where a IP subnetwork is partitioned (may be due to some layer 2 >problems) where each partition may have tis own DR/BDR. In this >case, when partitions are merged, R4 will be the new DR for the >final healed IP subnetwork. R3 will become DR-other. R2 remains >as BDR (unless there is another BDR from other partition). > >--Phil > > > >-----Original Message----- > From: Zebaida, Dror (Dror) [mailto:dzebaida@AVAYA.COM] >Sent: Tuesday, May 13, 2003 8:04 AM >To: OSPF@DISCUSS.MICROSOFT.COM >Subject: Re: DR election > > >I understand that if there is already a DR/BDR then R4 will not >become the DR. >However, when an interface transitions out of the WAIT state, if >it thinks it is >alone on the network, it declares itself the DR. If after that, >it connects to the >network, there are 2 routers declaring themselves DR. In our case >R3 and R4. >At this stage, is a new DR elected, or does R3 remain the DR. > >The scenario I am describing is R4 is conneced to the network >after it transitioned >out of the WAIT state (after 40 seconds) > >Thanks > > > >-----Original Message----- > From: Russ White [mailto:ruwhite@CISCO.COM] >Sent: Tuesday, May 13, 2003 2:56 PM >To: OSPF@DISCUSS.MICROSOFT.COM >Subject: Re: DR election > > >As long as there is already a dr on the link, R4 would not take >over as the >DR. Or it shouldn't. Think of it this way: The DR isn't elected >first, the >BDR is. Then the routers attached to the link "discover" there is >no DR, >and promote the BDR to DR, and elect a new BDR. > >:-) > >Russ > >On Tue, 13 May 2003, Dror wrote: > > > Hi, > > > > I have a question regarding a DR election algorithm. If I >have a netowrk > > with 3 routers R1,-R3, each having the same priority and with >router IDs > > 0.0.0.1, 0.0.0.2, 0.0.0.3 respectively. > > > > After a DR election process is done, R3 will be DR, R2 will be >BDR and R1 > > will be DR-Other. This is the result of the DR election >process since R3 > > has the largest router ID. > > > > If I add a new router R4 with router ID 0.0.0.4, do I expect >R4 to become > > the DR, or does it just become another DR-other since there is >already a DR > > in the network. > > > > Does the result depend on whether R4 is connected to the >network when it is > > still in the WAIT state, or the result is the same >nevertheless. > > > > Thanks > > Dror > > > >__________________________________ >riw@cisco.com CCIE <>< Grace Alone ___________________________________________________ Get email that means BUSINESS! me @ mycompany.com. Just Rs.1499/year. To start, click http://www.rediffmailpro.com From owner-ospf@DISCUSS.MICROSOFT.COM Tue May 13 12:14:10 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18750 for ; Tue, 13 May 2003 12:14:10 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.009BE36D@cherry.ease.lsoft.com>; Tue, 13 May 2003 12:17:09 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 666401 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 13 May 2003 12:17:09 -0400 Received: from 171.70.144.185 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 13 May 2003 12:17:09 -0400 Received: from cisco.com (171.71.163.13) by halt-in.cisco.com with ESMTP; 13 May 2003 09:17:15 -0800 Received: from cisco.com (dhcp-128-107-163-147.cisco.com [128.107.163.147]) by mira-sjc5-f.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AGD95874; Tue, 13 May 2003 09:24:16 -0700 (PDT) X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-19.7.x i686) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3EC110C8.628A8A7E@cisco.com> Date: Tue, 13 May 2003 08:35:36 -0700 Reply-To: Mailing List Sender: Mailing List From: Michael J Barnes Subject: Re: DR election To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit "Zebaida, Dror (Dror)" wrote: > > I understand that if there is already a DR/BDR then R4 will not become the DR. > However, when an interface transitions out of the WAIT state, if it thinks it is > alone on the network, it declares itself the DR. If after that, it connects to the > network, there are 2 routers declaring themselves DR. In our case R3 and R4. > At this stage, is a new DR elected, or does R3 remain the DR. > > The scenario I am describing is R4 is conneced to the network after it transitioned > out of the WAIT state (after 40 seconds) In this case there is a "collision" which will force a DR election, so R4 will become the DR and R3 will become DROTHER. Regards, Michael From owner-ospf@DISCUSS.MICROSOFT.COM Tue May 13 13:37:59 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21543 for ; Tue, 13 May 2003 13:37:59 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.009BE742@cherry.ease.lsoft.com>; Tue, 13 May 2003 13:40:59 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 666635 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 13 May 2003 13:40:59 -0400 Received: from 131.241.15.4 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 13 May 2003 13:40:59 -0400 Received: from netkeeper.sj.nec.com (netkeeper.sj.nec.com [131.241.31.2]) by mail4.nec.com (/) with ESMTP id h4DHevoX010713 for ; Tue, 13 May 2003 10:40:57 -0700 (PDT) Received: from necsun.tdd.sj.nec.com (localhost [127.0.0.1]) by netkeeper.sj.nec.com (/) with ESMTP id h4DHepmR023972 for ; Tue, 13 May 2003 10:40:51 -0700 (PDT) Received: from bunny.tdd.sj.nec.com (bunny.tdd.sj.nec.com [131.241.9.33]) by necsun.tdd.sj.nec.com (8.12.8/8.12.8) with ESMTP id h4DHULsC024362 for ; Tue, 13 May 2003 10:30:21 -0700 (PDT) Received: from ems12 (ems12 [131.241.5.17]) by bunny.tdd.sj.nec.com with SMTP id h4DHUJYS024772 for ; Tue, 13 May 2003 10:30:19 -0700 (PDT) References: <3EC0F2E5.5020507@redback.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Message-ID: <163601c31977$c0b2c5d0$1105f183@b90.tdd.sj.nec.com> Date: Tue, 13 May 2003 10:47:41 -0700 Reply-To: Mailing List Sender: Mailing List From: kamatchi soundaram Subject: Re: DR election To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Yes! i did see that happened. You can easily simulate this condition. Connect R1, R2 and R3 to the Network first. In that R3 will become DR and R2 will Become BDR. Meantime, start R4 separately (mean, don't hook-up the R4 Lan cable to the network.). In that case, since R4 didn't see anyother router in the network, it will become as DR. Then when you put the R4 also into the network, R4 will become the DR and R2 remained as BDR. Well! i had seen this scenario in my network. GKS. ----- Original Message ----- From: "Acee Lindem" To: Sent: Tuesday, May 13, 2003 6:28 AM Subject: Re: DR election > Hi Dror, > > Zebaida, Dror (Dror) wrote: > > I understand that if there is already a DR/BDR then R4 will not become the DR. > > As described succintly in Russ White's e-mail below. > > > However, when an interface transitions out of the WAIT state, if it thinks it is > > alone on the network, it declares itself the DR. If after that, it connects to the > > network, there are 2 routers declaring themselves DR. In our case R3 and R4. > > At this stage, is a new DR elected, or does R3 remain the DR. > > > > The scenario I am describing is R4 is conneced to the network after it transitioned > > out of the WAIT state (after 40 seconds) > > This really should never happen on a broadcast or NBMA network unless you have > some type of connectivity or an NBMA configuration problem. I have seen it happen > on an NBMA network if the existing DR and BDR are using the RFC 2328 appendix C > suggested X.25 poll interval of 2 minutes and all the DR eligible neighbors are > not configured as eligible on all the DR eligible routers. When it happens a new > DR election will be triggered and R4 will become DR. I believe R2 will remain > as BDR. > > Thanks, > Acee > > > > > Thanks > > > > > > > > -----Original Message----- > > From: Russ White [mailto:ruwhite@CISCO.COM] > > Sent: Tuesday, May 13, 2003 2:56 PM > > To: OSPF@DISCUSS.MICROSOFT.COM > > Subject: Re: DR election > > > > > > As long as there is already a dr on the link, R4 would not take over as the > > DR. Or it shouldn't. Think of it this way: The DR isn't elected first, the > > BDR is. Then the routers attached to the link "discover" there is no DR, > > and promote the BDR to DR, and elect a new BDR. > > > > :-) > > > > Russ > > > > On Tue, 13 May 2003, Dror wrote: > > > > > >>Hi, > >> > >>I have a question regarding a DR election algorithm. If I have a netowrk > >>with 3 routers R1,-R3, each having the same priority and with router IDs > >>0.0.0.1, 0.0.0.2, 0.0.0.3 respectively. > >> > >>After a DR election process is done, R3 will be DR, R2 will be BDR and R1 > >>will be DR-Other. This is the result of the DR election process since R3 > >>has the largest router ID. > >> > >>If I add a new router R4 with router ID 0.0.0.4, do I expect R4 to become > >>the DR, or does it just become another DR-other since there is already a DR > >>in the network. > >> > >>Does the result depend on whether R4 is connected to the network when it is > >>still in the WAIT state, or the result is the same nevertheless. > >> > >>Thanks > >>Dror > >> > > > > > > __________________________________ > > riw@cisco.com CCIE <>< Grace Alone > > > > > -- > Acee > From owner-ospf@DISCUSS.MICROSOFT.COM Tue May 13 13:39:39 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21702 for ; Tue, 13 May 2003 13:39:39 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.009BE697@cherry.ease.lsoft.com>; Tue, 13 May 2003 13:42:40 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 666654 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 13 May 2003 13:42:40 -0400 Received: from 131.241.15.4 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 13 May 2003 13:42:40 -0400 Received: from netkeeper2.sj.nec.com (netkeeper2.sj.nec.com [131.241.31.10]) by mail4.nec.com (/) with ESMTP id h4DHgcoX010785 for ; Tue, 13 May 2003 10:42:38 -0700 (PDT) Received: from necsun.tdd.sj.nec.com (localhost [127.0.0.1]) by netkeeper2.sj.nec.com (/) with ESMTP id h4DHgVGQ021932 for ; Tue, 13 May 2003 10:42:31 -0700 (PDT) Received: from bunny.tdd.sj.nec.com (bunny.tdd.sj.nec.com [131.241.9.33]) by necsun.tdd.sj.nec.com (8.12.8/8.12.8) with ESMTP id h4DHW2sC024380 for ; Tue, 13 May 2003 10:32:02 -0700 (PDT) Received: from ems12 (ems12 [131.241.5.17]) by bunny.tdd.sj.nec.com with SMTP id h4DHW0YS024783 for ; Tue, 13 May 2003 10:32:00 -0700 (PDT) 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.4133.2400 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Message-ID: <164101c31977$fd087b60$1105f183@b90.tdd.sj.nec.com> Date: Tue, 13 May 2003 10:49:23 -0700 Reply-To: Mailing List Sender: Mailing List From: kamatchi soundaram Subject: Re: DR election To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit R4 will become DR. GKS ----- Original Message ----- From: "Zebaida, Dror (Dror)" To: Sent: Tuesday, May 13, 2003 6:46 AM Subject: Re: DR election > Hi Phil, > > I don't mean exactly a partitioned network. This is what I mean: > > 1) R1 -------------------R2 > | > | N10 > | > R3 > > 2) All connected and R3 is elected to be the DR since it has the highest router ID. > > 3) R4 is configured to run ospf on an interface belonging to N10. However it is not physically connecet to N10 > > 4) R4 is transitioned out of it WAIT state after 40 seconds thinking it's alone on N10 (not receiving any HELLOS) > > 5) R4 is physically connected to N10 > > 6) R1/R2/R3 all send HELLOS with R3 DR and R2 BDR. R4 sends HELLO with R4 DR > > 7) what happens now??? R3 remains DR or R4 is selected to be DR. > > > Hope this is clear > Thanks > Dror > > > > > > > -----Original Message----- > From: Phil Chen [mailto:pchen@PROQUENT.COM] > Sent: Tuesday, May 13, 2003 4:29 PM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Re: DR election > > > If I understand you correctly, you are talking about a situation where a IP subnetwork is partitioned (may be due to some layer 2 problems) where each partition may have tis own DR/BDR. In this case, when partitions are merged, R4 will be the new DR for the final healed IP subnetwork. R3 will become DR-other. R2 remains as BDR (unless there is another BDR from other partition). > > --Phil > > > > -----Original Message----- > From: Zebaida, Dror (Dror) [mailto:dzebaida@AVAYA.COM] > Sent: Tuesday, May 13, 2003 8:04 AM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Re: DR election > > > I understand that if there is already a DR/BDR then R4 will not become the DR. > However, when an interface transitions out of the WAIT state, if it thinks it is > alone on the network, it declares itself the DR. If after that, it connects to the > network, there are 2 routers declaring themselves DR. In our case R3 and R4. > At this stage, is a new DR elected, or does R3 remain the DR. > > The scenario I am describing is R4 is conneced to the network after it transitioned > out of the WAIT state (after 40 seconds) > > Thanks > > > > -----Original Message----- > From: Russ White [mailto:ruwhite@CISCO.COM] > Sent: Tuesday, May 13, 2003 2:56 PM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Re: DR election > > > As long as there is already a dr on the link, R4 would not take over as the > DR. Or it shouldn't. Think of it this way: The DR isn't elected first, the > BDR is. Then the routers attached to the link "discover" there is no DR, > and promote the BDR to DR, and elect a new BDR. > > :-) > > Russ > > On Tue, 13 May 2003, Dror wrote: > > > Hi, > > > > I have a question regarding a DR election algorithm. If I have a netowrk > > with 3 routers R1,-R3, each having the same priority and with router IDs > > 0.0.0.1, 0.0.0.2, 0.0.0.3 respectively. > > > > After a DR election process is done, R3 will be DR, R2 will be BDR and R1 > > will be DR-Other. This is the result of the DR election process since R3 > > has the largest router ID. > > > > If I add a new router R4 with router ID 0.0.0.4, do I expect R4 to become > > the DR, or does it just become another DR-other since there is already a DR > > in the network. > > > > Does the result depend on whether R4 is connected to the network when it is > > still in the WAIT state, or the result is the same nevertheless. > > > > Thanks > > Dror > > > > __________________________________ > riw@cisco.com CCIE <>< Grace Alone > > From owner-ospf@DISCUSS.MICROSOFT.COM Tue May 13 13:48:28 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22052 for ; Tue, 13 May 2003 13:48:27 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.009BE5EE@cherry.ease.lsoft.com>; Tue, 13 May 2003 13:51:28 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 666684 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 13 May 2003 13:51:28 -0400 Received: from 131.241.15.4 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 13 May 2003 13:51:28 -0400 Received: from netkeeper.sj.nec.com (netkeeper.sj.nec.com [131.241.31.2]) by mail4.nec.com (/) with ESMTP id h4DHpQoX011285 for ; Tue, 13 May 2003 10:51:26 -0700 (PDT) Received: from necsun.tdd.sj.nec.com (localhost [127.0.0.1]) by netkeeper.sj.nec.com (/) with ESMTP id h4DHpJb4024330 for ; Tue, 13 May 2003 10:51:19 -0700 (PDT) Received: from bunny.tdd.sj.nec.com (bunny.tdd.sj.nec.com [131.241.9.33]) by necsun.tdd.sj.nec.com (8.12.8/8.12.8) with ESMTP id h4DHensC024502 for ; Tue, 13 May 2003 10:40:49 -0700 (PDT) Received: from ems12 (ems12 [131.241.5.17]) by bunny.tdd.sj.nec.com with SMTP id h4DHelYS027441 for ; Tue, 13 May 2003 10:40:47 -0700 (PDT) References: <20030413161512.92837.qmail@web10908.mail.yahoo.com> <3E9B898C.9050304@redback.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Message-ID: <167001c31979$36ef1040$1105f183@b90.tdd.sj.nec.com> Date: Tue, 13 May 2003 10:58:09 -0700 Reply-To: Mailing List Sender: Mailing List From: kamatchi soundaram Subject: Re: Multiple un-numbered serial links between two routers To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit See in lined with [GKS] GKS. ----- Original Message ----- From: "Acee Lindem" To: Sent: Monday, April 14, 2003 9:24 PM Subject: Re: Multiple un-numbered serial links between two routers > j j wrote: > > Can OSPF support this? Seems like there isn't enough > > information in Router LSA to distinctly identify the > > interfaces for nexthop information. > > JJ, > > You are correct - a router link in a router LSA doesn't > provide you with enough information to distinctly identify > parallel unnumbered links. Note that an IP next hop > address is not necessary for a point-to-point link (see section > 16.1.1 in RFC 2328). [GKS] -- For equal cost multipath calculation, i would think, even in the un-num p2p links the correct interface(local) need to be determined to forward the packet in the right interface.?? > > > > > Or is this an invalid configuration on a router? > > There are a number of implementation choices one could > make. One is to consider all the advertised parallel unnumbered > links valid as long there is bi-directional connectivity > via one of them. Another would be to consider the configuration > invalid. > > > > > > > thanks > > > > __________________________________________________ > > Do you Yahoo!? > > Yahoo! Tax Center - File online, calculators, forms, and more > > http://tax.yahoo.com > > > > Hope this helps, > -- > Acee > From owner-ospf@DISCUSS.MICROSOFT.COM Tue May 13 14:08:51 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22951 for ; Tue, 13 May 2003 14:08:42 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.009BE8A2@cherry.ease.lsoft.com>; Tue, 13 May 2003 14:11:35 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 666816 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 13 May 2003 14:11:35 -0400 Received: from 131.241.15.4 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 13 May 2003 14:11:34 -0400 Received: from netkeeper.sj.nec.com (netkeeper.sj.nec.com [131.241.31.2]) by mail4.nec.com (/) with ESMTP id h4DIBKoX012401 for ; Tue, 13 May 2003 11:11:20 -0700 (PDT) Received: from necsun.tdd.sj.nec.com (localhost [127.0.0.1]) by netkeeper.sj.nec.com (/) with ESMTP id h4DIBALw024854 for ; Tue, 13 May 2003 11:11:10 -0700 (PDT) Received: from bunny.tdd.sj.nec.com (bunny.tdd.sj.nec.com [131.241.9.33]) by necsun.tdd.sj.nec.com (8.12.8/8.12.8) with ESMTP id h4DHxgsC024670 for ; Tue, 13 May 2003 10:59:42 -0700 (PDT) Received: from ems12 (ems12 [131.241.5.17]) by bunny.tdd.sj.nec.com with SMTP id h4DHxeYS011714 for ; Tue, 13 May 2003 10:59:40 -0700 (PDT) References: <12f501c31360$c89dd180$1105f183@b90.tdd.sj.nec.com> <3EBE960D.2000604@redback.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Message-ID: <168501c3197b$da3c69d0$1105f183@b90.tdd.sj.nec.com> Date: Tue, 13 May 2003 11:17:02 -0700 Reply-To: Mailing List Sender: Mailing List From: kamatchi soundaram Subject: Re: un-num p2p clarification. To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Acee Lindem" To: Sent: Sunday, May 11, 2003 11:27 AM Subject: Re: un-num p2p clarification. > kamatchi soundaram wrote: > > Hi all, > > > > I have the following two doubts in Un-num p2p for OSPF. > > > > 1) If I bring up an un-num p2p with one of the other interface's valid ip > > address (ex. LAN), does the un-num p2p need to be associated with the same > > "AREA" with which the LAN has been associated??? or can be associated with > > an different area address. > > More clearly: The router R1 has three interfaces, but interface #1 has a > > valid IP address and other two are un-num p2p interfaces. So, the two un-num > > p2p interfaces will use the Ip address of Interface #1. Assume, the > > interface #1 got associated with Area 0. Now the question is, can the un-num > > p2p interfaces be associted to some other AREA other than AREA 0 or not?? > > There is no protocol requirement for the two interfaces to be in the same > area or for the P2P link's reference interface to be advertised at all. > Consider the following set-up: | eth 0 R1 | | | | R2 | eth0 In the above set-up, R1 and R2 connected by two un-num p2p interfaces. And both does have one Lan interface. The R1 router Lsa will have info as, two point to point links and one stub link. Lets assume the un-num p2p interface MIB-2 index are 2 and 3 for p2p-1 and p2p-2 of Router R1 respectively. So, this will be advertised in the LSA as a link data. Similarly, R2 will have two p2p links and one stub links. Assume mib-2 if index are 4 and 5 for R2's p2p links. Then during next-hop calculation, the correct interface has to be associated with the correct other end of the p2p link from R1 to R2. If we don't have any interface reference detail (that is the other end interface mib index value associated with either neighbor table or interface table), then there is a chance that always for the both p2p-1 and p2p-2 of the R2 will be reachable via the same p2p-1 of R1. Which will basically makes the packet forward always in the same interface. Either p2p-1 or p2p-2 of R1 to R2. Even though the next hop address will be the same R2 router's lan ip address to reach the R2's lan network, the packet originating interfaces at R1 are different. Well! there is a practical requirement for the above scenario. So, don't discard that the above set-up will not be used anywhere. We face the above scenario in our SONET and WDM networks. > > Thanks in advance, > > GKS. > > > > > -- > Acee > From owner-ospf@DISCUSS.MICROSOFT.COM Tue May 13 15:03:16 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24803 for ; Tue, 13 May 2003 15:03:16 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.009BE8A1@cherry.ease.lsoft.com>; Tue, 13 May 2003 15:06:17 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 667049 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 13 May 2003 15:06:17 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 13 May 2003 15:06:16 -0400 Received: from redback.com (login003.redback.com [155.53.12.55]) by prattle.redback.com (Postfix) with ESMTP id 0DC05C4368 for ; Tue, 13 May 2003 12:06:15 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <12f501c31360$c89dd180$1105f183@b90.tdd.sj.nec.com> <3EBE960D.2000604@redback.com> <168501c3197b$da3c69d0$1105f183@b90.tdd.sj.nec.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3EC14224.3040300@redback.com> Date: Tue, 13 May 2003 15:06:12 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: un-num p2p clarification. To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit kamatchi soundaram wrote: > ----- Original Message ----- > From: "Acee Lindem" > To: > Sent: Sunday, May 11, 2003 11:27 AM > Subject: Re: un-num p2p clarification. > > > >>kamatchi soundaram wrote: >> >>>Hi all, >>> >>> I have the following two doubts in Un-num p2p for OSPF. >>> >>>1) If I bring up an un-num p2p with one of the other interface's valid >> > ip > >>>address (ex. LAN), does the un-num p2p need to be associated with the >> > same > >>>"AREA" with which the LAN has been associated??? or can be associated >> > with > >>>an different area address. >>>More clearly: The router R1 has three interfaces, but interface #1 has a >>>valid IP address and other two are un-num p2p interfaces. So, the two >> > un-num > >>>p2p interfaces will use the Ip address of Interface #1. Assume, the >>>interface #1 got associated with Area 0. Now the question is, can the >> > un-num > >>>p2p interfaces be associted to some other AREA other than AREA 0 or >> > not?? > >>There is no protocol requirement for the two interfaces to be in the same >>area or for the P2P link's reference interface to be advertised at all. >> > > Consider the following set-up: > | eth 0 > R1 > | | > | | > R2 > | eth0 > In the above set-up, R1 and R2 connected by two un-num p2p interfaces. And > both does have one Lan interface. > The R1 router Lsa will have info as, two point to point links and one stub > link. Lets assume the un-num p2p interface MIB-2 index are 2 and 3 for p2p-1 > and p2p-2 of Router R1 respectively. So, this will be advertised in the LSA > as a link data. > Similarly, R2 will have two p2p links and one stub links. Assume mib-2 if > index are 4 and 5 for R2's p2p links. > > Then during next-hop calculation, the correct interface has to be > associated with the correct other end of the p2p link from R1 to R2. If we > don't have any interface reference detail (that is the other end interface > mib index value associated with either neighbor table or interface table), > then there is a chance that always for the both p2p-1 and p2p-2 of the R2 > will be reachable via the same p2p-1 of R1. Which will basically makes the > packet forward always in the same interface. Either p2p-1 or p2p-2 of R1 to > R2. > > Even though the next hop address will be the same R2 router's lan ip > address to reach the R2's lan network, the packet originating interfaces at > R1 are different. > > Well! there is a practical requirement for the above scenario. So, don't > discard that the above set-up will not be used anywhere. We face the above > scenario in our SONET and WDM networks. GKS, You simply use your view of which P2P links are up (as per your router LSA). The backlink check can use any link for the area in question as per footnote 23 on page 182 of RFC 2328 (I can't remember who previous pointed this out but thanks). Thanks, Acee > > >>>Thanks in advance, >>>GKS. >>> >> >> >>-- >>Acee >> > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Tue May 13 18:56:41 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03185 for ; Tue, 13 May 2003 18:56:41 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.009BEFAB@cherry.ease.lsoft.com>; Tue, 13 May 2003 18:59:41 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 667449 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 13 May 2003 18:59:41 -0400 Received: from 128.123.3.39 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 13 May 2003 18:49:41 -0400 Received: from dns1.nmsu.edu (dns1.NMSU.Edu [128.123.3.5]) by bubba.NMSU.Edu (8.10.2+Sun/8.9.0) with ESMTP id h4DMncU08823 for ; Tue, 13 May 2003 16:49:38 -0600 (MDT) Received: from hector.NMSU.Edu (hector.NMSU.Edu [128.123.34.9]) by dns1.nmsu.edu (8.9.3/8.9.0) with ESMTP id QAA94027; Tue, 13 May 2003 16:49:39 -0600 (MDT) Received: from localhost (juanrubi@localhost) by hector.NMSU.Edu (AIX4.3/8.9.3/8.9.0) with ESMTP id QAA21676; Tue, 13 May 2003 16:49:39 -0600 X-Authentication-Warning: hector.NMSU.Edu: juanrubi owned process doing -bs MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Tue, 13 May 2003 16:49:39 -0600 Reply-To: Mailing List Sender: Mailing List From: "Juan A. Rubio" Subject: link-local/optional capabilities signaling To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi everyone, I have a question regarding exchange of optional capabilities in OSPFv2 in general and link-local signaling in particular. In draft-nguyen-ospf-lls-02.txt the LLS block may be attached to type-1 and type-2 packets (HELLOs and DBDs). Is there any reason to not attach these LLS blocks to other packet types?. I know that in OSPFv2 the Options field is present in Hello packets, DBD packets and the LSA header. That means that there is optional capabilities info in packets other that type-1 and type-2, in particular type-3, UPDATE packets. So, is there any reason to specifically avoid link-local/optional capabilities signaling in other packet types?. Juan From owner-ospf@DISCUSS.MICROSOFT.COM Tue May 13 19:09:47 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03576 for ; Tue, 13 May 2003 19:09:46 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.009BF173@cherry.ease.lsoft.com>; Tue, 13 May 2003 19:12:44 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 667510 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 13 May 2003 19:12:44 -0400 Received: from 171.71.177.254 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 13 May 2003 19:12:44 -0400 Received: from rtp-iosxdm1.cisco.com (rtp-iosxdm1.cisco.com [64.102.16.214]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h4DNAPNb018462 for ; Tue, 13 May 2003 16:10:45 -0700 (PDT) Received: (lhnguyen@localhost) by rtp-iosxdm1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id TAA07508 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 13 May 2003 19:10:25 -0400 (EDT) References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <20030513231025.GY19109@rtp-iosxdm1.cisco.com> Date: Tue, 13 May 2003 19:10:25 -0400 Reply-To: Mailing List Sender: Mailing List From: Liem Nguyen Subject: Re: link-local/optional capabilities signaling To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Precedence: list Juan, On Tue, May 13, 2003 at 04:49:39PM -0600, Juan A. Rubio wrote: > Hi everyone, > > I have a question regarding exchange of optional capabilities in OSPFv2 in > general and link-local signaling in particular. > > In draft-nguyen-ospf-lls-02.txt the LLS block may be attached to type-1 > and type-2 packets (HELLOs and DBDs). Is there any reason to not attach > these LLS blocks to other packet types?. I know that in OSPFv2 the Options > field is present in Hello packets, DBD packets and the LSA header. That > means that there is optional capabilities info in packets other that > type-1 and type-2, in particular type-3, UPDATE packets. So, is there any > reason to specifically avoid link-local/optional capabilities signaling in > other packet types?. There's no technical reason, just unnecessary. The purpose is to "signal" and exchange capability, so it's suffice to convey such information during neighbor/adjacency bring-up. Liem From owner-ospf@DISCUSS.MICROSOFT.COM Wed May 14 06:36:09 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11621 for ; Wed, 14 May 2003 06:36:09 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.009C00CB@cherry.ease.lsoft.com>; Wed, 14 May 2003 6:39:09 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 669564 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 14 May 2003 06:39:09 -0400 Received: from 202.54.64.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 14 May 2003 06:39:09 -0400 Received: by GANESH with Internet Mail Service (5.5.2653.19) id ; Wed, 14 May 2003 16:09:05 +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, 14 May 2003 16:09:20 +0530 Reply-To: Mailing List Sender: Mailing List From: "Jeyanath Minto J - CTD, Chennai." Subject: Type-7 LSAs forwarding Address To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi all, exerted from rfc3101 section 2.3 " When a router is forced to pick a forwarding address for a Type-7 LSA, preference should be given first to the router's internal addresses (provided internal addressing is supported). " This will happen only when NSSA ASBR connected to unnumbered point to point link to adjacent AS. am i right ? And choosing stub network address for forwarding address is to avoid point to point extra hop. am i right ? Cheers Minto From owner-ospf@DISCUSS.MICROSOFT.COM Wed May 14 08:37:58 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15740 for ; Wed, 14 May 2003 08:37:57 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.009C04DB@cherry.ease.lsoft.com>; Wed, 14 May 2003 8:40:58 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 669836 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 14 May 2003 08:40:58 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 14 May 2003 08:40:58 -0400 Received: from redback.com (login001.redback.com [155.53.12.18]) by prattle.redback.com (Postfix) with ESMTP id 0783C50FAD6 for ; Wed, 14 May 2003 05:40:57 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3EC2394C.5000603@redback.com> Date: Wed, 14 May 2003 08:40:44 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Type-7 LSAs forwarding Address To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Jeyanath Minto J - CTD, Chennai. wrote: > Hi all, Good Morning Minto, > > exerted from rfc3101 section 2.3 > " > When a router is forced to pick a forwarding address for a Type-7 > LSA, preference should be given first to the router's internal > addresses (provided internal addressing is supported). > " > > This will happen only when NSSA ASBR connected to unnumbered point to point > link to adjacent AS. am i right ? No - it will happen any time the external route's next hop address is not part of the NSSA's OSPF topology. > > And choosing stub network address for forwarding address is to avoid point > to point extra hop. am i right ? If the option 2 is selected from the available options in section 12.4.1.1 of RFC 2328 this is correct. Selecting a stub network will also prevent the extra hop on broadcast and NBMA networks (since the subnet prefix is always installed in the route table). > > Cheers > Minto > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Wed May 14 15:10:58 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01474 for ; Wed, 14 May 2003 15:10:58 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.009C0E41@cherry.ease.lsoft.com>; Wed, 14 May 2003 15:13:59 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 670933 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 14 May 2003 15:13:58 -0400 Received: from 207.217.120.12 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 14 May 2003 15:13:53 -0400 Received: from user-2ivfl9h.dialup.mindspring.com ([165.247.213.49] helo=earthlink.net) by harrier.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 19G1hI-0002zr-00 for ospf@discuss.microsoft.com; Wed, 14 May 2003 12:13:52 -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: <3EC295A4.85776110@earthlink.net> Date: Wed, 14 May 2003 12:14:44 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: ABR Summaries causing bad OSPF route paths To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Group, I ran into what I call sys admin error in specifiying ABR summaries. This is due to the fact that each summary only carries a single weight. These summaries are advertised outside of the area. However, a better/shorter path may be to one of the summarized subnets via a different ABR but that 2nd ABR has summarized the subnet with a higher weight. Should / are RFCs existing that handle the incorrect summarizing and/or the improper weighting of the summaries? Should OSPF have a intelligence that tries to identify the proper level of summaries and/ or the weighting of such? Yes, I do realize that summaries have benefits dealing with decreased route tables, fewer OSPF control packets, etc. Mitchell Erblich Sr Software Engineer From owner-ospf@DISCUSS.MICROSOFT.COM Wed May 14 15:23:30 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02292 for ; Wed, 14 May 2003 15:23:30 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.009C0E04@cherry.ease.lsoft.com>; Wed, 14 May 2003 15:26:32 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 670946 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 14 May 2003 15:26:31 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 14 May 2003 15:26:30 -0400 Received: from redback.com (login001.redback.com [155.53.12.18]) by prattle.redback.com (Postfix) with ESMTP id AB0CF6D2184 for ; Wed, 14 May 2003 12:26:23 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <3EC295A4.85776110@earthlink.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3EC2984F.4000704@redback.com> Date: Wed, 14 May 2003 15:26:07 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: ABR Summaries causing bad OSPF route paths To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Erblichs wrote: > Group, > > I ran into what I call sys admin error in specifiying > ABR summaries. This is due to the fact that each summary > only carries a single weight. These summaries are > advertised outside of the area. However, a better/shorter > path may be to one of the summarized subnets via a > different ABR but that 2nd ABR has summarized the subnet > with a higher weight. > > Should / are RFCs existing that handle the incorrect > summarizing and/or the improper weighting of the summaries? > > Should OSPF have a intelligence that tries to identify > the proper level of summaries and/ or the weighting of such? The algorithm is well defined. The summary cost is the highest cost of any of its components. It is not incorrect - anytime you summarize of aggregate routes, you're going to run into some level of information loss. This is true in any routing protocol. OSPF has the advantage allowing the same ranges to overlap so that an adminstrator can make the tradeoff between reducing the amount of information advertised and optimal routing. > > Yes, I do realize that summaries have benefits dealing with > decreased route tables, fewer OSPF control packets, etc. > > Mitchell Erblich > Sr Software Engineer > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Wed May 14 15:37:56 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02741 for ; Wed, 14 May 2003 15:37:56 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.009C0E81@cherry.ease.lsoft.com>; Wed, 14 May 2003 15:40:58 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 670963 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 14 May 2003 15:40:57 -0400 Received: from 65.244.18.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 14 May 2003 15:40:57 -0400 Received: from avianserver.aviancommunications.com by blackhole.proquent.com via smtpd (for discuss.microsoft.com [209.119.0.18]) with ESMTP; Wed, 14 May 2003 15:42:09 -0400 Received: from guinness.aviancommunications.com ([192.168.18.11]) by AVIANSERVER.aviancommunications.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 14 May 2003 15:41:06 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: ABR Summaries causing bad OSPF route paths Thread-Index: AcMaTQEulMXJdx4uTdmcCYvLaiMTiAAAd+1w X-OriginalArrivalTime: 14 May 2003 19:41:06.0343 (UTC) FILETIME=[C2BDCB70:01C31A50] Message-ID: <249ED70AF90130429A83AA992183BF5D6A7B43@guinness.aviancommunications.com> Date: Wed, 14 May 2003 15:41:07 -0400 Reply-To: Mailing List Sender: Mailing List From: Phil Chen Subject: Re: ABR Summaries causing bad OSPF route paths To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA02741 I am not sure your weight concept, and I am assume you are refering to cost to destinations. If you care about optimal routing of IP packet to a particular set of destinations, for example an IP subnetwork, you can exclude it from your high level summary. There isn't much OSPF intellegence can help you here. Route summary is a tool to allow you to essentially defeat OSPF itelligence in exchange for scalability. At least OSPF gives admin a choice. --Phil -----Original Message----- From: Erblichs [mailto:erblichs@EARTHLINK.NET] Sent: Wednesday, May 14, 2003 3:15 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: ABR Summaries causing bad OSPF route paths Group, I ran into what I call sys admin error in specifiying ABR summaries. This is due to the fact that each summary only carries a single weight. These summaries are advertised outside of the area. However, a better/shorter path may be to one of the summarized subnets via a different ABR but that 2nd ABR has summarized the subnet with a higher weight. Should / are RFCs existing that handle the incorrect summarizing and/or the improper weighting of the summaries? Should OSPF have a intelligence that tries to identify the proper level of summaries and/ or the weighting of such? Yes, I do realize that summaries have benefits dealing with decreased route tables, fewer OSPF control packets, etc. Mitchell Erblich Sr Software Engineer From owner-ospf@DISCUSS.MICROSOFT.COM Wed May 14 16:13:28 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03804 for ; Wed, 14 May 2003 16:13:28 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.009C1074@cherry.ease.lsoft.com>; Wed, 14 May 2003 16:16:30 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 671043 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 14 May 2003 16:16:29 -0400 Received: from 207.159.120.60 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 14 May 2003 16:16:29 -0400 Received: by xmxpita.excite.com (Postfix, from userid 110) id 71C733DDF; Wed, 14 May 2003 16:16:26 -0400 (EDT) Received: from [64.47.48.10] by xprdmailfe9.nwk.excite.com via HTTP; Wed, 14 May 2003 16:16:26 EST X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: ID = ce00c10647f1b9e7db16a67db0936ee4 MIME-Version: 1.0 X-Sender: dgoodspe@excite.com X-Mailer: PHP Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <20030514201626.71C733DDF@xmxpita.excite.com> Date: Wed, 14 May 2003 16:16:26 -0400 Reply-To: Mailing List Sender: Mailing List From: Don Goodspeed Subject: Re: ABR Summaries causing bad OSPF route paths To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Mitchell, If there is a need to give a set of routes a different cost than the overall summary range, advertise a subset range on both ABRs. For example, take the range 128.0.0.0/16 advertised on both ABRs. One can then advertise a subset of this same range (128.0.192.0/24) and the costing of this range of routes only would give the 2nd ABR preference. -don --- On Wed 05/14, Erblichs < erblichs@EARTHLINK.NET > wrote: From: Erblichs [mailto: erblichs@EARTHLINK.NET] To: OSPF@DISCUSS.MICROSOFT.COM Date: Wed, 14 May 2003 12:14:44 -0700 Subject: ABR Summaries causing bad OSPF route paths Group,

I ran into what I call sys admin error in specifiying
ABR summaries. This is due to the fact that each summary
only carries a single weight. These summaries are
advertised outside of the area. However, a better/shorter
path may be to one of the summarized subnets via a
different ABR but that 2nd ABR has summarized the subnet
with a higher weight.

Should / are RFCs existing that handle the incorrect
summarizing and/or the improper weighting of the summaries?

Should OSPF have a intelligence that tries to identify
the proper level of summaries and/ or the weighting of such?

Yes, I do realize that summaries have benefits dealing with
decreased route tables, fewer OSPF control packets, etc.

Mitchell Erblich
Sr Software Engineer
_______________________________________________ Join Excite! - http://www.excite.com The most personalized portal on the Web! From owner-ospf@DISCUSS.MICROSOFT.COM Wed May 14 16:55:39 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05083 for ; Wed, 14 May 2003 16:55:39 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.009C10EC@cherry.ease.lsoft.com>; Wed, 14 May 2003 16:58:41 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 671131 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 14 May 2003 16:58:41 -0400 Received: from 207.217.120.232 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 14 May 2003 16:58:41 -0400 Received: from user-2ivfl9h.dialup.mindspring.com ([165.247.213.49] helo=earthlink.net) by flamingo.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 19G3Kh-0001hw-00 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 14 May 2003 13:58:40 -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: <20030514201626.71C733DDF@xmxpita.excite.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3EC2AE34.522DF45B@earthlink.net> Date: Wed, 14 May 2003 13:59:32 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: ABR Summaries causing bad OSPF route paths To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Don, Thanks, I know how to summarize subnets. This investigation was requested by the "customer" after we reviewed this "issue". I was looking for a algorithm that can intelliently 2nd guess a sys admin and might want to log a message. I was thinking about a summarization tree.. Mitchell Erblich Sr Software Engineer Don Goodspeed wrote: > > Mitchell, > > If there is a need to give a set of routes a different cost than > the overall summary range, advertise a subset range on both ABRs. > > For example, take the range 128.0.0.0/16 advertised on both ABRs. > One can then advertise a subset of this same range (128.0.192.0/24) > and the costing of this range of routes only would give the 2nd ABR > preference. > > -don > > --- On Wed 05/14, Erblichs < erblichs@EARTHLINK.NET > wrote: > From: Erblichs [mailto: erblichs@EARTHLINK.NET] > To: OSPF@DISCUSS.MICROSOFT.COM > Date: Wed, 14 May 2003 12:14:44 -0700 > Subject: ABR Summaries causing bad OSPF route paths > > Group,

I ran into what I call sys admin error in specifiying
ABR summaries. This is due to the fact that each summary
only carries a single weight. These summaries are
advertised outside of the area. However, a better/shorter
path may be to one of the summarized subnets via a
different ABR but that 2nd ABR has summarized the subnet
with a higher weight.

Should / are RFCs existing that handle the incorrect
summarizing and/or the improper weighting of the summaries?

Should OSPF have a intelligence that tries to identify
the proper level of summaries and/ or the weighting of such?

Yes, I do realize that summaries have benefits dealing with
decreased route tables, fewer OSPF control packets, etc.

Mitchell Erblich
Sr Software Engineer
> > _______________________________________________ > Join Excite! - http://www.excite.com > The most personalized portal on the Web! From owner-ospf@DISCUSS.MICROSOFT.COM Wed May 14 17:18:40 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06031 for ; Wed, 14 May 2003 17:18:39 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.009C1273@cherry.ease.lsoft.com>; Wed, 14 May 2003 17:21:42 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 671186 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 14 May 2003 17:21:42 -0400 Received: from 65.244.18.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 14 May 2003 17:21:42 -0400 Received: from avianserver.aviancommunications.com by blackhole.proquent.com via smtpd (for discuss.microsoft.com [209.119.0.18]) with ESMTP; Wed, 14 May 2003 17:22:54 -0400 Received: from guinness.aviancommunications.com ([192.168.18.11]) by AVIANSERVER.aviancommunications.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 14 May 2003 17:21:50 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: ABR Summaries causing bad OSPF route paths Thread-Index: AcMaXWzbnqcDYCA+RCOdUgtG8bTkxwAAB0Xw X-OriginalArrivalTime: 14 May 2003 21:21:50.0521 (UTC) FILETIME=[D55A2A90:01C31A5E] Message-ID: <249ED70AF90130429A83AA992183BF5D6A7B45@guinness.aviancommunications.com> Date: Wed, 14 May 2003 17:21:51 -0400 Reply-To: Mailing List Sender: Mailing List From: Phil Chen Subject: Re: ABR Summaries causing bad OSPF route paths Comments: To: Erblichs To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA06031 Mitchell, I wasn't really refering it as a software tool, I meant it as OSPF feature. I casually pick the word "tool" to describe various protocol feature that you can use to solve your problems. Your CLI should have some command to allow you to do just what I said. That is the tool you are refering to. Some vendor also have a GUI based OSPF configuration tool, but I wasn't really refering to those tools in my original message. --Phil -----Original Message----- From: Erblichs [mailto:erblichs@earthlink.net] Sent: Wednesday, May 14, 2003 5:12 PM To: Phil Chen Subject: Re: ABR Summaries causing bad OSPF route paths Phil Chen, Are you saying that the route summary tool is released with your router's OS or are you saying that it is in the public domain or ..? Mitchell Erblich -------------- Phil Chen wrote: > > I am not sure your weight concept, and I am assume you are refering to cost to destinations. If you care about optimal routing of IP packet to a particular set of destinations, for example an IP subnetwork, you can exclude it from your high level summary. There isn't much OSPF intellegence can help you here. Route summary is a tool to allow you to essentially defeat OSPF itelligence in exchange for scalability. At least OSPF gives admin a choice. > > --Phil > > -----Original Message----- > From: Erblichs [mailto:erblichs@EARTHLINK.NET] > Sent: Wednesday, May 14, 2003 3:15 PM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: ABR Summaries causing bad OSPF route paths > > Group, > > I ran into what I call sys admin error in specifiying > ABR summaries. This is due to the fact that each summary > only carries a single weight. These summaries are > advertised outside of the area. However, a better/shorter > path may be to one of the summarized subnets via a > different ABR but that 2nd ABR has summarized the subnet > with a higher weight. > > Should / are RFCs existing that handle the incorrect > summarizing and/or the improper weighting of the summaries? > > Should OSPF have a intelligence that tries to identify > the proper level of summaries and/ or the weighting of such? > > Yes, I do realize that summaries have benefits dealing with > decreased route tables, fewer OSPF control packets, etc. > > Mitchell Erblich > Sr Software Engineer From owner-ospf@DISCUSS.MICROSOFT.COM Fri May 16 10:48:54 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27941 for ; Fri, 16 May 2003 10:48:54 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.009C518F@cherry.ease.lsoft.com>; Fri, 16 May 2003 10:51:56 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 666477 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 16 May 2003 10:51:54 -0400 Received: from 66.218.93.139 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 16 May 2003 10:51:54 -0400 Received: from [203.200.20.226] by web41805.mail.yahoo.com via HTTP; Fri, 16 May 2003 15:51:53 BST MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <20030516145153.47027.qmail@web41805.mail.yahoo.com> Date: Fri, 16 May 2003 15:51:53 +0100 Reply-To: Mailing List Sender: Mailing List From: =?iso-8859-1?q?John=20Smith?= Subject: cost of link changing To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit Hi, I want to know if the cost of a link between two routers can change anytime because of some Traffic Engg. module running or something? Say this link gets congested then can i somehow increase the cost of this link so that OSPF may take appropriate actions (choose an alternative lesser congested link, etc)? OR does the cost once assigned to the link remain constant and unchanged unless the admin actually changes it manually? Thanks, Smith __________________________________________________ Yahoo! Plus For a better Internet experience http://www.yahoo.co.uk/btoffer From owner-ospf@DISCUSS.MICROSOFT.COM Fri May 16 10:58:43 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28122 for ; Fri, 16 May 2003 10:58:43 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.009C5276@cherry.ease.lsoft.com>; Fri, 16 May 2003 11:01:46 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 666550 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 16 May 2003 11:01:46 -0400 Received: from 65.244.18.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 16 May 2003 11:01:46 -0400 Received: from avianserver.aviancommunications.com by blackhole.proquent.com via smtpd (for discuss.microsoft.com [209.119.0.18]) with ESMTP; Fri, 16 May 2003 11:02:58 -0400 Received: from guinness.aviancommunications.com ([192.168.18.11]) by AVIANSERVER.aviancommunications.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 16 May 2003 11:01:54 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: cost of link changing Thread-Index: AcMburpJuT9G11zLTdyId5id5a7aAQAADXmA X-OriginalArrivalTime: 16 May 2003 15:01:54.0837 (UTC) FILETIME=[16E45450:01C31BBC] Message-ID: <249ED70AF90130429A83AA992183BF5D6A7B48@guinness.aviancommunications.com> Date: Fri, 16 May 2003 11:01:55 -0400 Reply-To: Mailing List Sender: Mailing List From: Phil Chen Subject: Re: cost of link changing To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA28122 Link costs typically are statically assigned. Achieving TE tasks with dynamic link cost changes can easily get you into trouble. One of the major problem is traffic oscillation. There are some researches in this area to use domainwide OSPF link cost adjustment to adopt your network to traffic pattern in hand, so in theory it is possible. But MPLS provides much better solution for TE. --Phil -----Original Message----- From: John Smith [mailto:jsmith4112003@YAHOO.CO.UK] Sent: Friday, May 16, 2003 10:52 AM To: OSPF@DISCUSS.MICROSOFT.COM Subject: cost of link changing Hi, I want to know if the cost of a link between two routers can change anytime because of some Traffic Engg. module running or something? Say this link gets congested then can i somehow increase the cost of this link so that OSPF may take appropriate actions (choose an alternative lesser congested link, etc)? OR does the cost once assigned to the link remain constant and unchanged unless the admin actually changes it manually? Thanks, Smith __________________________________________________ Yahoo! Plus For a better Internet experience http://www.yahoo.co.uk/btoffer From owner-ospf@DISCUSS.MICROSOFT.COM Fri May 16 11:09:50 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28543 for ; Fri, 16 May 2003 11:09:50 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.009C50E3@cherry.ease.lsoft.com>; Fri, 16 May 2003 11:12:53 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 666595 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 16 May 2003 11:12:53 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 16 May 2003 11:12:41 -0400 Received: from redback.com (login001.redback.com [155.53.12.18]) by prattle.redback.com (Postfix) with ESMTP id E69B0744141 for ; Fri, 16 May 2003 08:12:39 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <20030516145153.47027.qmail@web41805.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3EC5001E.1030500@redback.com> Date: Fri, 16 May 2003 11:13:34 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: cost of link changing To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit John Smith wrote: > Hi, > I want to know if the cost of a link between two routers can change anytime because of > some Traffic Engg. module running or something? Hi John, There is no provision for dynamically modifying the cost in base OSPF. For traffic engineered paths, IGP metric is just one factor that may be considered. > > Say this link gets congested then can i somehow increase the cost of this link so that > OSPF may take appropriate actions (choose an alternative lesser congested link, etc)? OR > does the cost once assigned to the link remain constant and unchanged unless the admin > actually changes it manually? In base OSPF, the cost will not change unless there is a configuration change (or possibly an underlying link speed change). There was a fairly good proposal to influence selection among equal-cost multipath routes based on congestion. It was never standardized and I'm not sure if anyone has implemented it. http://www.watersprings.org/pub/id/draft-ietf-ospf-omp-02.txt Thanks, Acee > > Thanks, > Smith > > > __________________________________________________ > Yahoo! Plus > For a better Internet experience > http://www.yahoo.co.uk/btoffer > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Fri May 16 11:10:47 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28581 for ; Fri, 16 May 2003 11:10:47 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.009C5240@cherry.ease.lsoft.com>; Fri, 16 May 2003 11:13:51 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 666615 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 16 May 2003 11:13:51 -0400 Received: from 209.119.0.100 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 16 May 2003 11:13:51 -0400 Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.009C525D@cherry.ease.lsoft.com>; Fri, 16 May 2003 11:13:51 -0400 Message-ID: Date: Fri, 16 May 2003 11:13:51 -0400 Reply-To: Mailing List Sender: Mailing List From: Mike Fox Subject: Changing router ID in OSPFv3 To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list The RFC for OSPFv2 in section 12.4.2 Network Links, describes this logic for when a designated router changes router ID: in those rare cases where a router's Router ID has changed, any network links advertisements that were originated with the router's previous Router ID must be flushed. Since the router may have no idea what it's previous Router ID might have been, these network links advertisements are indicated by having their Link State ID equal to one of the router's IP interface addresses and their Advertising Router not equal to the router's current Router ID (see Section 13.4 for more details). Then section 13.4 Receiving self-originated link state, says: A self-originated advertisement is detected when either .... (2) the advertisement is a network links advertisement and its Link State ID is equal to one of the router's own IP interface addresses. In RFC 2740 a self-originated advertisement is simplified to simply be one whose LS originator matches your router ID. So is there any equivalent function to the above in OSPFv3? Since link state IDs in network LSAs are now interface IDs which are very unlikely to be unique, the above-described situation seems impossible to detect in OSPFv3. Therefore in OSPFv3 perhaps the only acceptable way to change router ID is to flush all old adverts first? Mike From owner-ospf@DISCUSS.MICROSOFT.COM Fri May 16 11:28:05 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29242 for ; Fri, 16 May 2003 11:28:05 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.009C528C@cherry.ease.lsoft.com>; Fri, 16 May 2003 11:31:08 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 666642 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 16 May 2003 11:31:07 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 16 May 2003 11:31:07 -0400 Received: from redback.com (login001.redback.com [155.53.12.18]) by prattle.redback.com (Postfix) with ESMTP id 09583744154 for ; Fri, 16 May 2003 08:31:06 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3EC50470.3030802@redback.com> Date: Fri, 16 May 2003 11:32:00 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Changing router ID in OSPFv3 To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi Mike, Mike Fox wrote: > The RFC for OSPFv2 in section 12.4.2 Network Links, describes this logic for > when a designated router changes router ID: > > in those rare cases where a router's > Router ID has changed, any network links advertisements that > were originated with the router's previous Router ID must be > flushed. Since the router may have no idea what it's > previous Router ID might have been, these network links > advertisements are indicated by having their Link State ID > equal to one of the router's IP interface addresses and > their Advertising Router not equal to the router's current > Router ID (see Section 13.4 for more details). > > Then section 13.4 Receiving self-originated link state, says: > > A self-originated advertisement is detected when either .... > (2) the advertisement is a network links > advertisement and its Link State ID is equal to one of the > router's own IP interface addresses. > > > In RFC 2740 a self-originated advertisement is simplified to simply be one > whose LS originator matches your router ID. > > So is there any equivalent function to the above in OSPFv3? Since link > state IDs in network LSAs are now interface IDs which are very unlikely to > be unique, the above-described situation seems impossible to detect in > OSPFv3. Therefore in OSPFv3 perhaps the only acceptable way to change > router ID is to flush all old adverts first? No need to do this. As long as all the routers on the network correctly identify the new DR in their router LSA links to the transit network (type 2), the stale network LSA shouldn't be used. This is one benefit of always identifying a router by it's router ID (in OSPFv2 it is identified in the type 2 link by it's address on the transit network). > > Mike > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Fri May 16 12:38:10 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02168 for ; Fri, 16 May 2003 12:38:09 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.009C536E@cherry.ease.lsoft.com>; Fri, 16 May 2003 12:41:13 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 666829 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 16 May 2003 12:41:12 -0400 Received: from 144.189.100.102 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 16 May 2003 12:41:12 -0400 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id h4GGfBDS026554 for ; Fri, 16 May 2003 09:41:11 -0700 (MST) Received: from xover.corp.mot.com (xover.corp.mot.com [10.1.148.18]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id h4GGf95i027460 for ; Fri, 16 May 2003 11:41:10 -0500 Received: by xover.corp.mot.com with Internet Mail Service (5.5.2653.19) id ; Fri, 16 May 2003 12:40:55 -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, 16 May 2003 12:42:51 -0400 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: cost of link changing To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi John, I think research in that regard has been done by AT&T folks. Check the page http://www.research.att.com/~jrex/#te Thanks, Vishwas -----Original Message----- From: John Smith [mailto:jsmith4112003@YAHOO.CO.UK] Sent: Friday, May 16, 2003 8:22 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: cost of link changing Hi, I want to know if the cost of a link between two routers can change anytime because of some Traffic Engg. module running or something? Say this link gets congested then can i somehow increase the cost of this link so that OSPF may take appropriate actions (choose an alternative lesser congested link, etc)? OR does the cost once assigned to the link remain constant and unchanged unless the admin actually changes it manually? Thanks, Smith From owner-ospf@DISCUSS.MICROSOFT.COM Fri May 16 17:04:56 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10873 for ; Fri, 16 May 2003 17:04:55 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.009C61D8@cherry.ease.lsoft.com>; Fri, 16 May 2003 17:07:57 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 667872 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 16 May 2003 17:07:57 -0400 Received: from 207.159.120.55 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 16 May 2003 17:07:57 -0400 Received: by xmxpita.excite.com (Postfix, from userid 110) id 9B1CD3CD5; Fri, 16 May 2003 17:07:55 -0400 (EDT) Received: from [64.47.48.10] by xprdmailfe4.nwk.excite.com via HTTP; Fri, 16 May 2003 17:07:55 EST X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: ID = ce00c10647f1b9e7db16a67db0936ee4 MIME-Version: 1.0 X-Sender: dgoodspe@excite.com X-Mailer: PHP Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <20030516210755.9B1CD3CD5@xmxpita.excite.com> Date: Fri, 16 May 2003 17:07:55 -0400 Reply-To: Mailing List Sender: Mailing List From: Don Goodspeed Subject: ietf-draft-ospf-mib-update-06 text for traps To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit OSPF WG, Wow. I cannot believe most of these have been in since RFC-1850. Anyways, just caught these today... 1. ospfVirtIfStateChange NOTIFICATION-TYPE DESCRIPTION "An ospfIfStateChange trap signifies that there ^^^^^^^^^^^^^^^^^ 2. ospfVirtNbrStateChange NOTIFICATION-TYPE DESCRIPTION "An ospfIfStateChange trap signifies that there ^^^^^^^^^^^^^^^^^ 3. ospfVirtIfConfigError NOTIFICATION-TYPE DESCRIPTION "An ospfConfigError trap signifies that a pack- ^^^^^^^^^^^^^^^ 4. ospfVirtIfRxBadPacket NOTIFICATION-TYPE DESCRIPTION "An ospfRxBadPacket trap signifies that an OSPF ^^^^^^^^^^^^^^^ 5. ospfVirtIfTxRetransmit NOTIFICATION-TYPE DESCRIPTION "An ospfTxRetransmit trap signifies than an ^^^^^^^^^^^^^^^^ And these three are new: 6. ospfRestartStatusChange NOTIFICATION-TYPE DESCRIPTION "An ospfRestartStatus trap signifies that ^^^^^^^^^^^^^^^^^ 7. ospfNbrRestartHelperStatusChange NOTIFICATION-TYPE DESCRIPTION "An ospfNbrRestartHelperStatus trap signifies that ^^^^^^^^^^^^^^^^^^^^^^^^^^ 8. ospfVirtNbrRestartHelperStatusChange NOTIFICATION-TYPE DESCRIPTION "An ospfVirtNbrRestartHelperStatus trap signifies that ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -don _______________________________________________ Join Excite! - http://www.excite.com The most personalized portal on the Web! From owner-ospf@DISCUSS.MICROSOFT.COM Sat May 17 03:05:18 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02309 for ; Sat, 17 May 2003 03:05:18 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.009C7103@cherry.ease.lsoft.com>; Sat, 17 May 2003 3:08:22 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 669132 for OSPF@DISCUSS.MICROSOFT.COM; Sat, 17 May 2003 03:08:22 -0400 Received: from 64.106.140.220 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sat, 17 May 2003 03:08:22 -0400 Received: from mail.apara.com (localhost.localdomain [127.0.0.1]) by mail.apara.com (8.11.6/8.11.6) with ESMTP id h4H7uBJ21990 for ; Sat, 17 May 2003 13:26:11 +0530 Received: from alok ([203.124.140.101]) (authenticated) by mail.apara.com (8.11.6/8.11.6) with ESMTP id h4H7u9321984 for ; Sat, 17 May 2003 13:26:10 +0530 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Message-ID: <039401c31c43$8b4a6140$81c802c0@alok> Date: Sat, 17 May 2003 12:41:23 +0530 Reply-To: Mailing List Sender: Mailing List From: alok Subject: multi-hop OSPF To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi, is there any draft etc. suggesting a "multi-hop" flavor of OSPF? What i need is: R1(OSPF)-----R2----R3(OSPF) R1 and R3 should form adjacencies.... [dont say "tunnel" ;-) ] just wondering if there is a draft or any work ever done to this effect.. -thanks and rgds Alok From owner-ospf@DISCUSS.MICROSOFT.COM Sat May 17 20:34:02 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18341 for ; Sat, 17 May 2003 20:34:02 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.009C8036@cherry.ease.lsoft.com>; Sat, 17 May 2003 20:37:06 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 671091 for OSPF@DISCUSS.MICROSOFT.COM; Sat, 17 May 2003 20:37:05 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sat, 17 May 2003 20:37:05 -0400 Received: from redback.com (montreal.redback.com [155.53.34.71]) by prattle.redback.com (Postfix) with ESMTP id F0468713AC0 for ; Sat, 17 May 2003 17:37:04 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; NetBSD i386; en-US; rv:1.1) Gecko/20020829 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <039401c31c43$8b4a6140$81c802c0@alok> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3EC6D5B0.2010801@redback.com> Date: Sat, 17 May 2003 17:37:04 -0700 Reply-To: Mailing List Sender: Mailing List From: Rikki Nguyen Subject: Re: multi-hop OSPF To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit just wondering what would be the usefulness of this? if R2 is not part of the OSPF routing domain, then it will not know of the routes exchanged between R1 and R3. all transit traffic will be dropped. if R2 did know about those routes, it won't be from OSPF. it would have to be from some other configuration or protocol. and if, by chance, that protocol isn't consistent with the way OSPF chooses its paths, you'll have routing loops on your hand. alok wrote: > Hi, > > is there any draft etc. suggesting a "multi-hop" flavor of OSPF? > > What i need is: > > R1(OSPF)-----R2----R3(OSPF) > > R1 and R3 should form adjacencies.... > > [dont say "tunnel" ;-) ] > > just wondering if there is a draft or any work ever done to this effect.. > > -thanks and rgds > Alok > From owner-ospf@DISCUSS.MICROSOFT.COM Mon May 19 01:11:24 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25695 for ; Mon, 19 May 2003 01:11:23 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.009C9DE4@cherry.ease.lsoft.com>; Mon, 19 May 2003 1:14:28 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 673452 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 19 May 2003 01:14:28 -0400 Received: from 129.188.136.101 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 19 May 2003 01:14:28 -0400 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h4J5ERSP025941 for ; Sun, 18 May 2003 22:14:27 -0700 (MST) Received: from xover.corp.mot.com (xover.corp.mot.com [10.1.148.18]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id h4J5EPbr031125 for ; Mon, 19 May 2003 00:14:25 -0500 Received: by xover.corp.mot.com with Internet Mail Service (5.5.2653.19) id ; Mon, 19 May 2003 01:14:10 -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: Mon, 19 May 2003 01:15:58 -0400 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: ietf-draft-ospf-mib-update-06 text for traps To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list I guess it goes on to show, the OSPF-TRAP-MIB isn't being used as extensively.:-) Would we want a similar MIB for OSPFv3(the current version of the draft doesn't have it)? Thanks, Vishwas -----Original Message----- From: Don Goodspeed [mailto:dgoodspe@EXCITE.COM] Sent: Saturday, May 17, 2003 2:38 AM To: OSPF@DISCUSS.MICROSOFT.COM Subject: ietf-draft-ospf-mib-update-06 text for traps OSPF WG, Wow. I cannot believe most of these have been in since RFC-1850. Anyways, just caught these today... 1. ospfVirtIfStateChange NOTIFICATION-TYPE DESCRIPTION "An ospfIfStateChange trap signifies that there ^^^^^^^^^^^^^^^^^ 2. ospfVirtNbrStateChange NOTIFICATION-TYPE DESCRIPTION "An ospfIfStateChange trap signifies that there ^^^^^^^^^^^^^^^^^ 3. ospfVirtIfConfigError NOTIFICATION-TYPE DESCRIPTION "An ospfConfigError trap signifies that a pack- ^^^^^^^^^^^^^^^ 4. ospfVirtIfRxBadPacket NOTIFICATION-TYPE DESCRIPTION "An ospfRxBadPacket trap signifies that an OSPF ^^^^^^^^^^^^^^^ 5. ospfVirtIfTxRetransmit NOTIFICATION-TYPE DESCRIPTION "An ospfTxRetransmit trap signifies than an ^^^^^^^^^^^^^^^^ And these three are new: 6. ospfRestartStatusChange NOTIFICATION-TYPE DESCRIPTION "An ospfRestartStatus trap signifies that ^^^^^^^^^^^^^^^^^ 7. ospfNbrRestartHelperStatusChange NOTIFICATION-TYPE DESCRIPTION "An ospfNbrRestartHelperStatus trap signifies that ^^^^^^^^^^^^^^^^^^^^^^^^^^ 8. ospfVirtNbrRestartHelperStatusChange NOTIFICATION-TYPE DESCRIPTION "An ospfVirtNbrRestartHelperStatus trap signifies that ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -don From owner-ospf@DISCUSS.MICROSOFT.COM Mon May 19 12:35:59 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26458 for ; Mon, 19 May 2003 12:35:44 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.009CD99B@cherry.ease.lsoft.com>; Mon, 19 May 2003 12:38:46 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 677236 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 19 May 2003 12:38:45 -0400 Received: from 207.217.120.46 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 19 May 2003 12:38:44 -0400 Received: from user-38ldve1.dialup.mindspring.com ([209.86.253.193] helo=earthlink.net) by grebe.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 19Hnet-0006Xq-00 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 19 May 2003 09:38: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: <039401c31c43$8b4a6140$81c802c0@alok> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3EC908D2.ADF525DD@earthlink.net> Date: Mon, 19 May 2003 09:39:46 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: multi-hop OSPF To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Alok, Why don't you / can't you form adj between R1 / R3 and eliminate R2? If R2 doesn't speak OSPF, then your "is there any draft etc. suggesting a "multi-hop" flavor of OSPF?" doesn't apply to R2, if such a RFC did exist? Mitchell Erblich Sr. Software Engineer alok wrote: > > Hi, > > is there any draft etc. suggesting a "multi-hop" flavor of OSPF? > > What i need is: > > R1(OSPF)-----R2----R3(OSPF) > > R1 and R3 should form adjacencies.... > > [dont say "tunnel" ;-) ] > > just wondering if there is a draft or any work ever done to this effect.. > > -thanks and rgds > Alok From owner-ospf@DISCUSS.MICROSOFT.COM Tue May 20 03:53:40 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02343 for ; Tue, 20 May 2003 03:53:39 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.009D5A6D@cherry.ease.lsoft.com>; Tue, 20 May 2003 3:56:45 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 683483 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 20 May 2003 03:56:45 -0400 Received: from 203.199.83.26 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 20 May 2003 03:56:44 -0400 Received: (qmail 22212 invoked by uid 510); 20 May 2003 07:56:41 -0000 Received: from unknown (203.197.138.201) by rediffmail.com via HTTP; 20 may 2003 07:56:41 -0000 MIME-Version: 1.0 Content-type: text/plain; format=flowed Content-Disposition: inline Message-ID: <20030520075641.22211.qmail@webmail16.rediffmail.com> Date: Tue, 20 May 2003 07:56:41 -0000 Reply-To: Mailing List Sender: Mailing List From: Vivek Dubey Subject: Re: ietf-draft-ospf-mib-update-06 text for traps To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Probably yes. Traps are really useful in notifying critical events to network manager. vivek On Mon, 19 May 2003 Manral, Vishwas wrote : >I guess it goes on to show, the OSPF-TRAP-MIB isn't being used >as >extensively.:-) > >Would we want a similar MIB for OSPFv3(the current version of the >draft >doesn't have it)? > >Thanks, >Vishwas > >-----Original Message----- > From: Don Goodspeed [mailto:dgoodspe@EXCITE.COM] >Sent: Saturday, May 17, 2003 2:38 AM >To: OSPF@DISCUSS.MICROSOFT.COM >Subject: ietf-draft-ospf-mib-update-06 text for traps > > >OSPF WG, > >Wow. I cannot believe most of these have been in since >RFC-1850. >Anyways, just caught these today... > >1. ospfVirtIfStateChange NOTIFICATION-TYPE > DESCRIPTION > "An ospfIfStateChange trap signifies that there > ^^^^^^^^^^^^^^^^^ >2. ospfVirtNbrStateChange NOTIFICATION-TYPE > DESCRIPTION > "An ospfIfStateChange trap signifies that there > ^^^^^^^^^^^^^^^^^ >3. ospfVirtIfConfigError NOTIFICATION-TYPE > DESCRIPTION > "An ospfConfigError trap signifies that a pack- > ^^^^^^^^^^^^^^^ >4. ospfVirtIfRxBadPacket NOTIFICATION-TYPE > DESCRIPTION > "An ospfRxBadPacket trap signifies that an OSPF > ^^^^^^^^^^^^^^^ >5. ospfVirtIfTxRetransmit NOTIFICATION-TYPE > DESCRIPTION > "An ospfTxRetransmit trap signifies than an > ^^^^^^^^^^^^^^^^ > >And these three are new: >6. ospfRestartStatusChange NOTIFICATION-TYPE > DESCRIPTION > "An ospfRestartStatus trap signifies that > ^^^^^^^^^^^^^^^^^ >7. ospfNbrRestartHelperStatusChange NOTIFICATION-TYPE > DESCRIPTION > "An ospfNbrRestartHelperStatus trap signifies that > ^^^^^^^^^^^^^^^^^^^^^^^^^^ >8. ospfVirtNbrRestartHelperStatusChange NOTIFICATION-TYPE > DESCRIPTION > "An ospfVirtNbrRestartHelperStatus trap signifies >that > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >-don ___________________________________________________ Get email that means BUSINESS! me @ mycompany.com. Just Rs.1499/year. To start, click http://www.rediffmailpro.com From owner-ospf@DISCUSS.MICROSOFT.COM Tue May 20 07:37:11 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06707 for ; Tue, 20 May 2003 07:37:11 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.009D644A@cherry.ease.lsoft.com>; Tue, 20 May 2003 7:40:16 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 684778 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 20 May 2003 07:40:16 -0400 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 20 May 2003 07:30:16 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06338; Tue, 20 May 2003 07:27:08 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200305201127.HAA06338@ietf.org> Date: Tue, 20 May 2003 07:27:07 -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-04.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF. Title : Prioritized Treatment of Specific OSPF Packets and Congestion Avoidance Author(s) : G. Choudhury et al. Filename : draft-ietf-ospf-scalability-04.txt Pages : 18 Date : 2003-5-19 This document recommends methods that are intended to improve the scalability and stability of large networks using OSPF (Open Shortest Path First) protocol. The methods include processing OSPF Hellos and LSA (Link State Advertisement) Acknowledgments at a higher priority compared to other OSPF packets, and other congestion avoidance procedures. Simulation results in support of some of the recommendations are given in the appendix sections. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-scalability-04.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-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ospf-scalability-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-5-19142145.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ospf-scalability-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ospf-scalability-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-19142145.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@DISCUSS.MICROSOFT.COM Tue May 20 08:50:09 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10900 for ; Tue, 20 May 2003 08:50:08 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.009D659E@cherry.ease.lsoft.com>; Tue, 20 May 2003 8:53:12 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 684990 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 20 May 2003 08:53:12 -0400 Received: from 192.128.134.71 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 20 May 2003 08:53:12 -0400 Received: from attrh5i.attrh.att.com ([135.38.62.12]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id h4KCjp0L028522 for ; Tue, 20 May 2003 07:53:09 -0500 (CDT) Received: from KCCLUST06EVS1.ugd.att.com (135.38.164.88) by attrh5i.attrh.att.com (6.5.032) id 3EC76602000CCE8C for OSPF@DISCUSS.MICROSOFT.COM; Tue, 20 May 2003 08:53:09 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: I-D ACTION:draft-ietf-ospf-scalability-04.txt Thread-Index: AcMexKdWfeaHQB6mR/m1iYsNcsJr1gACJu6w Message-ID: <73656AE8EE4C9C4D9FFF9DBFEAE9A00F223C1D@KCCLUST06EVS1.ugd.att.com> Date: Tue, 20 May 2003 07:53:09 -0500 Reply-To: Mailing List Sender: Mailing List From: "Choudhury, Gagan L, ALABS" Subject: Re: I-D ACTION:draft-ietf-ospf-scalability-04.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA10900 Hi All, This is a revised version based on comments on the list and comments from the WG chairs. Main changes are in Section 2 (Recommendations) and Appendix C (Other Recommendations). We would like to thank everybody who provided comments for significantly improving the quality of the draft. Gagan Choudhury -----Original Message----- From: Internet-Drafts@IETF.ORG [mailto:Internet-Drafts@IETF.ORG] Sent: Tuesday, May 20, 2003 7:27 AM To: OSPF@DISCUSS.MICROSOFT.COM Subject: I-D ACTION:draft-ietf-ospf-scalability-04.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF. Title : Prioritized Treatment of Specific OSPF Packets and Congestion Avoidance Author(s) : G. Choudhury et al. Filename : draft-ietf-ospf-scalability-04.txt Pages : 18 Date : 2003-5-19 This document recommends methods that are intended to improve the scalability and stability of large networks using OSPF (Open Shortest Path First) protocol. The methods include processing OSPF Hellos and LSA (Link State Advertisement) Acknowledgments at a higher priority compared to other OSPF packets, and other congestion avoidance procedures. Simulation results in support of some of the recommendations are given in the appendix sections. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-scalability-04.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-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ospf-scalability-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From owner-ospf@DISCUSS.MICROSOFT.COM Tue May 20 19:39:29 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05983 for ; Tue, 20 May 2003 19:39:29 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.009D8603@cherry.ease.lsoft.com>; Tue, 20 May 2003 19:39:28 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 663435 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 20 May 2003 19:39:28 -0400 Received: from 204.192.44.242 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 20 May 2003 19:39:28 -0400 Received: (qmail 13417 invoked from network); 20 May 2003 23:39:28 -0000 Received: from bigbird.xebeo.com (192.168.0.21) by lxmail.xebeo.com with SMTP; 20 May 2003 23:39:28 -0000 Received: from bigbird.xebeo.com (localhost.localdomain [127.0.0.1]) by bigbird.xebeo.com (8.9.3/8.9.3) with ESMTP id TAA10433 for ; Tue, 20 May 2003 19:39:27 -0400 X-Mailer: exmh version 2.1.1 10/15/1999 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <200305202339.TAA10433@bigbird.xebeo.com> Date: Tue, 20 May 2003 19:39:27 -0400 Reply-To: Mailing List Sender: Mailing List From: Rohit Dube Subject: 57th IETF OSPF WG Meeting To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list We will be meeting in Vienna. Please send me and Acee any potential agenda items. Thanks, Rohit and Acee. From owner-ospf@DISCUSS.MICROSOFT.COM Wed May 21 01:29:03 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12702 for ; Wed, 21 May 2003 01:29:03 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.009D9236@cherry.ease.lsoft.com>; Wed, 21 May 2003 1:29:00 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 664364 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 21 May 2003 01:29:00 -0400 Received: from 203.199.83.39 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 21 May 2003 01:28:58 -0400 Received: (qmail 28495 invoked by uid 510); 21 May 2003 05:28:55 -0000 Received: from unknown (203.197.138.201) by rediffmail.com via HTTP; 21 may 2003 05:28:55 -0000 MIME-Version: 1.0 Content-type: text/plain; format=flowed Content-Disposition: inline Message-ID: <20030521052855.28494.qmail@webmail29.rediffmail.com> Date: Wed, 21 May 2003 05:28:55 -0000 Reply-To: Mailing List Sender: Mailing List From: Vivek Dubey Subject: Re: ospf-scalability-04.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Gagan, 2. Recommendations (1) ......"While receiving a packet from a neighbor and while transmitting a packet to a neighbor, try to process a "high priority" packet ahead of a "low priority" packet" Few questions ------------- Mainly from implementors view ............ The point to treat packets with higher/lower priority based on receiving from particular NBR is not very clear. 1) OSPF might be having multiple interfaces (each interface in turn having multiple NBRs). IP will pass all OSPF packets ...where they can be treated with high/low priority based on above classification. So while processing these high priority packets (hellos/acks), is it required to choose them as per NBR ....... if so which NBR will be given higher priority. It would be better if we just process all hellos/acks with higher priority (won't it save much overhead). 2) Ospf acks (delayed ones also) are sent in response to LSU packets. So to give priority to a "ack to be transmitted to a NBR", received LSU should be processed fast. Not very clear to me...... is there some conflict here ??? thanks, vivek On Tue, 20 May 2003 Choudhury, Gagan L, ALABS wrote : >Hi All, > This is a revised version based on comments on the list and >comments > from the WG chairs. Main changes are in Section 2 >(Recommendations) and >Appendix C (Other Recommendations). We would like to thank >everybody who >provided comments for significantly improving the quality of the >draft. > > Gagan Choudhury > >-----Original Message----- > From: Internet-Drafts@IETF.ORG >[mailto:Internet-Drafts@IETF.ORG] >Sent: Tuesday, May 20, 2003 7:27 AM >To: OSPF@DISCUSS.MICROSOFT.COM >Subject: I-D ACTION:draft-ietf-ospf-scalability-04.txt > > >A New Internet-Draft is available from the on-line >Internet-Drafts directories. >This draft is a work item of the Open Shortest Path First IGP >Working Group of the IETF. > > Title : Prioritized Treatment of Specific OSPF >Packets and > Congestion Avoidance > Author(s) : G. Choudhury et al. > Filename : draft-ietf-ospf-scalability-04.txt > Pages : 18 > Date : 2003-5-19 > >This document recommends methods that are intended to improve >the >scalability and stability of large networks using OSPF (Open >Shortest >Path First) protocol. The methods include processing OSPF Hellos >and >LSA (Link State Advertisement) Acknowledgments at a higher >priority >compared to other OSPF packets, and other congestion avoidance >procedures. Simulation results in support of some of the >recommendations are given in the appendix sections. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-ospf-scalability-04.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-04.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE >/internet-drafts/draft-ietf-ospf-scalability-04.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use >this > feature, insert the command "ENCODING mime" before the >"FILE" > command. To decode the response(s), you will need >"munpack" or > a MIME-compliant mail reader. Different MIME-compliant >mail readers > exhibit different behavior, especially when dealing >with > "multipart" MIME messages (i.e. documents which have >been split > up into multiple messages), so check your local >documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail >reader >implementation to automatically retrieve the ASCII version of >the >Internet-Draft. ___________________________________________________ Get email that means BUSINESS! me @ mycompany.com. Just Rs.1499/year. To start, click http://www.rediffmailpro.com From owner-ospf@DISCUSS.MICROSOFT.COM Wed May 21 10:02:08 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21522 for ; Wed, 21 May 2003 10:02:08 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.009D9D86@cherry.ease.lsoft.com>; Wed, 21 May 2003 10:02:05 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 666325 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 21 May 2003 10:02:05 -0400 Received: from 192.128.134.71 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 21 May 2003 10:02:05 -0400 Received: from attrh5i.attrh.att.com ([135.38.62.12]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id h4LE1rxo013190 for ; Wed, 21 May 2003 09:02:04 -0500 (CDT) Received: from KCCLUST06EVS1.ugd.att.com (135.38.164.88) by attrh5i.attrh.att.com (6.5.032) id 3EC7660200147443 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 21 May 2003 10:02:04 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: ospf-scalability-04.txt Thread-Index: AcMfWe8iFIagMjw3R62rJSgcFkEY6gAQrSuQ Message-ID: <73656AE8EE4C9C4D9FFF9DBFEAE9A00F223C20@KCCLUST06EVS1.ugd.att.com> Date: Wed, 21 May 2003 09:02:03 -0500 Reply-To: Mailing List Sender: Mailing List From: "Choudhury, Gagan L, ALABS" Subject: Re: ospf-scalability-04.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA21522 Vivek, Thanks for your comments on Recommendation 1. Here are the responses to the two points you make. With regards, Gagan Point 1: Recommendation 1 basically says to give higher priority to hellos/acks over other OSPF packets both during transmitting them and during receiving them. It does not say anything about whether priority is to be given to one neighbor over others during processing. It also does not say whether "high priority" class and "low" priority class has to be per neighbor or globally. So your suggestion of "just process all hellos/acks with higher priority" is included. Point 2: Ack is generated based on received LSU. However, we do not recommend all received LSUs to be treated at higher priority since in that case almost all received OSPF packets will be at a higher priority and the basic purpose of prioritization of Hellos/Acks over others will be defeated. We recommend that once an Ack has been generated it should go to its intended destination at a higher priority (even though the received LSU that caused this Ack is not given higher priority). We simulated this scheme and as you will see from Table 2 in Appendix B.2 just prioritizing Hellos and Acks (and not the received LSU that caused the Ack) can significantly improve scalability and stability. -----Original Message----- From: Vivek Dubey [mailto:vivek_ospf@REDIFFMAIL.COM] Sent: Wednesday, May 21, 2003 1:29 AM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: ospf-scalability-04.txt Gagan, 2. Recommendations (1) ......"While receiving a packet from a neighbor and while transmitting a packet to a neighbor, try to process a "high priority" packet ahead of a "low priority" packet" Few questions ------------- Mainly from implementors view ............ The point to treat packets with higher/lower priority based on receiving from particular NBR is not very clear. 1) OSPF might be having multiple interfaces (each interface in turn having multiple NBRs). IP will pass all OSPF packets ...where they can be treated with high/low priority based on above classification. So while processing these high priority packets (hellos/acks), is it required to choose them as per NBR ....... if so which NBR will be given higher priority. It would be better if we just process all hellos/acks with higher priority (won't it save much overhead). 2) Ospf acks (delayed ones also) are sent in response to LSU packets. So to give priority to a "ack to be transmitted to a NBR", received LSU should be processed fast. Not very clear to me...... is there some conflict here ??? thanks, vivek From owner-ospf@DISCUSS.MICROSOFT.COM Wed May 21 16:13:29 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07183 for ; Wed, 21 May 2003 16:13:28 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.009DA93B@cherry.ease.lsoft.com>; Wed, 21 May 2003 16:13:27 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 663908 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 21 May 2003 16:13:26 -0400 Received: from 207.217.120.46 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 21 May 2003 16:13:26 -0400 Received: from user-38ldvnm.dialup.mindspring.com ([209.86.254.246] helo=earthlink.net) by grebe.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 19IZxl-0004uk-00 for ospf@discuss.microsoft.com; Wed, 21 May 2003 13:13:25 -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: <3ECBDE27.540A0F39@earthlink.net> Date: Wed, 21 May 2003 13:14:31 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: draft ospf-scalability-04.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Comments:: Possible problems... 2. Recommendations 1) Classify "all" ... Looking at a storm of Hello packets may starve other OSPF packets from being processed. Try simulating 400 nbrs sending a hello every 10 ms. Queues tend to be finite and dropped low priority packets may result due to queue overflows. Recieved packets arrive in FIFO order, so to process after classification may require time stamping packets. This would minimally allow detection of illegally minimally spaced rexmits. 3) Use of Exponential Backoff algor.. Ethernet uses a Backoff algorithm... In this type of environment, wouldn't local congestion (congestion within a subnet) cause the backoff to occur anyway due to increased collisions? 4) Implicit congestion ... ... exceeds a certain "high water mark" then Shouldn't we exponentially decrease (#3) the LSA rexmit rate? We have to assume that we are in a heterogeneous environment (some routers don't support congestion control) and that the internal router's queues could be full AND take some time to process... ... falls below a certain "low water mark" then the normal rate of sending ... Should a TCP like method of gradually increasing the LSA retransmit rate be implimented? Wouldn't this remove / significantly remove the chance of "LSA rexmit thrashing". Mitchell Erblich Sr Software Engineer From owner-ospf@DISCUSS.MICROSOFT.COM Thu May 22 10:14:22 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15648 for ; Thu, 22 May 2003 10:14:21 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.009DC952@cherry.ease.lsoft.com>; Thu, 22 May 2003 10:14:21 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 666637 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 22 May 2003 10:14:20 -0400 Received: from 192.128.166.71 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 22 May 2003 10:14:20 -0400 Received: from attrh5i.attrh.att.com ([135.38.62.12]) by almso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id h4MD0cqC022274 for ; Thu, 22 May 2003 10:14:20 -0400 (EDT) Received: from KCCLUST06EVS1.ugd.att.com (135.38.164.88) by attrh5i.attrh.att.com (6.5.032) id 3EC76602001AD9A1 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 22 May 2003 10:14:19 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: draft ospf-scalability-04.txt Thread-Index: AcMf1Y3EQ8txoKLJS3uF0Z32xVooBwAjxYzA Message-ID: <73656AE8EE4C9C4D9FFF9DBFEAE9A00F223C22@KCCLUST06EVS1.ugd.att.com> Date: Thu, 22 May 2003 09:14:16 -0500 Reply-To: Mailing List Sender: Mailing List From: "Choudhury, Gagan L, ALABS" Subject: Re: draft ospf-scalability-04.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA15648 Mitchell, Thanks for your comments. The responses are in-line. With regards, Gagan -----Original Message----- From: Erblichs [mailto:erblichs@EARTHLINK.NET] Sent: Wednesday, May 21, 2003 4:15 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: draft ospf-scalability-04.txt Comments:: Possible problems... 2. Recommendations 1) Classify "all" ... Looking at a storm of Hello packets may starve other OSPF packets from being processed. Try simulating 400 nbrs sending a hello every 10 ms. Queues tend to be finite and dropped low priority packets may result due to queue overflows. Recieved packets arrive in FIFO order, so to process after classification may require time stamping packets. This would minimally allow detection of illegally minimally spaced rexmits. Response: In the example you have, the steady-state hello rate is so high that perhaps the processor cannot keep up with it. Note that this is a steady state problem. 400 Hellos are coming every 10 ms all the time. In this example the Hello traffic would swamp themselves (even if they are at higher priorities) and many hellos can be dropped which is widely considered to be undesirable. In addition of course the large steady-state load of hellos would slow down and cause to drop the incoming LSAs as well. The only way to solve this problem is perhaps to use a very fast processor or increase the Hello interval. Now two points to make. Firstly, it is widely regarded that it is undesirable to lose Hellos (since that could declare an adjacency down when it is actually up) and so under congestion (either caused by Hellos or LSAs) it is still preferable to give priority to Hellos. Secondly, by prioritization or any other congestion avoidance technique we can only hope to avoid a transient congestion problem (such as a sudden rush of change LSAs caused by a large failure event). If there is a steady-state congestion problem such as you point out then no prioritization or congestion avoidance technique can solve it unless you get rid of the steady-state congestion with faster processor or by permanently slowing down the steady-state traffic. 3) Use of Exponential Backoff algor.. Ethernet uses a Backoff algorithm... In this type of environment, wouldn't local congestion (congestion within a subnet) cause the backoff to occur anyway due to increased collisions? Response: Yes, some natural backoff will happen due to congestion itself but it is still desirable to have explicit backoff to avoid congestion. Also, retransmissions usually result from an internally triggered timer and at least in some implementations retransmissions may be sent out soon after this internal timer triggers even though there is a large queue of incoming messages (includes perhaps an Ack that could disable this retransmission) that have not been processed yet. In such a situation it is better to explicitly increase the retransmission timer to reduce retransmission traffic. 4) Implicit congestion ... ... exceeds a certain "high water mark" then Shouldn't we exponentially decrease (#3) the LSA rexmit rate? We have to assume that we are in a heterogeneous environment (some routers don't support congestion control) and that the internal router's queues could be full AND take some time to process... ... falls below a certain "low water mark" then the normal rate of sending ... Should a TCP like method of gradually increasing the LSA retransmit rate be implimented? Wouldn't this remove / significantly remove the chance of "LSA rexmit thrashing". Response: We have a simple scheme with only two rates of sending LSAs to a neighbor, the higher rate during "no congestion" and the lower rate during "congestion". To avoid thrashing between the two rates we use a "high water mark" and a "low water mark". Your suggestion is to further enhance the scheme with multiple rates. An implementor can certainly do that. However, we would prefer to specify only the simple scheme (which we have seen to have benefits through simulation studies) and would like to leave it up to the implementor to do further enhancements to the simple scheme. Another point to note is that Recommendation 4 slows down all LSAs (both new and retransmissions) during congestion whereas Recommendation 3 progressively slows down the successive retransmissions of the same LSA. We noted this at the end of Recommendation 4. Mitchell Erblich Sr Software Engineer From owner-ospf@DISCUSS.MICROSOFT.COM Thu May 22 10:33:40 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16438 for ; Thu, 22 May 2003 10:33:39 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.009DC9F7@cherry.ease.lsoft.com>; Thu, 22 May 2003 10:33:40 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 666703 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 22 May 2003 10:33:40 -0400 Received: from 203.199.83.38 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 22 May 2003 10:33:39 -0400 Received: (qmail 22472 invoked by uid 510); 22 May 2003 14:33:37 -0000 Received: from unknown (203.197.138.201) by rediffmail.com via HTTP; 22 may 2003 14:33:37 -0000 MIME-Version: 1.0 Content-type: text/plain; format=flowed Content-Disposition: inline Message-ID: <20030522143337.22471.qmail@webmail28.rediffmail.com> Date: Thu, 22 May 2003 14:33:37 -0000 Reply-To: Mailing List Sender: Mailing List From: Vivek Dubey Subject: Re: draft ospf-scalability-04.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Mitchell, Comments inlined... Looking at a storm of Hello packets may starve other OSPF packets from being processed. Try simulating 400 nbrs sending a hello every 10 ms. vivek>> >"It might happen. But for sub second hellos (10ms) , >Rtr dead interval will be around 40ms. >Issues involved here will not just be to >prevent OSPF from causing LSA storm but ..... >CPU , buffer and queue lengths of the processor. >Morever we need to process these sub-second hellos >or else NBR will be dead." Recieved packets arrive in FIFO order, so to process after classification may require time stamping packets. This would minimally allow detection of illegally minimally spaced rexmits. vivek> >"Are you referring RXMT LSUs ?? Since point 1 >processes the acks on higher priority(reducing >the chances of RXMTs) wont it be overhead. Probably >simulation will show the effect correctly." Ethernet uses a Backoff algorithm... In this type of environment, wouldn't local congestion (congestion within a subnet) cause the backoff to occur anyway due to increased collisions? vivek>> >"But it will not prevent OSPF to contribute to >LSA storm ???" regards, vivek On Thu, 22 May 2003 Erblichs wrote : >Comments:: > > Possible problems... > > > 2. Recommendations > > 1) Classify "all" ... > > Looking at a storm of Hello packets may >starve > other OSPF packets from being processed. >Try > simulating 400 nbrs sending a hello >every 10 ms. > > Queues tend to be finite and dropped >low > priority packets may result due to >queue > overflows. > > Recieved packets arrive in FIFO order, >so to > process after classification may >require > time stamping packets. This would >minimally > allow detection of illegally minimally >spaced > rexmits. > > > 3) Use of Exponential Backoff algor.. > > Ethernet uses a Backoff algorithm... In >this > type of environment, wouldn't local >congestion > (congestion within a subnet) cause > the backoff to occur anyway due to >increased > collisions? > > 4) Implicit congestion ... > > > ... exceeds a certain "high water mark" >then > > > Shouldn't we exponentially decrease (#3) >the > LSA rexmit rate? We have to assume that >we > are in a heterogeneous environment >(some > routers don't support congestion >control) and > that the internal router's queues could >be > full AND take some time to process... > > ... falls below a certain "low water >mark" then > the normal rate of sending ... > > Should a TCP like method of gradually >increasing > the LSA retransmit rate be implimented? >Wouldn't > this remove / significantly remove the >chance of > "LSA rexmit thrashing". > > > Mitchell Erblich > Sr Software Engineer ___________________________________________________ Get email that means BUSINESS! me @ mycompany.com. Just Rs.1499/year. To start, click http://www.rediffmailpro.com From owner-ospf@DISCUSS.MICROSOFT.COM Fri May 23 06:28:19 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00964 for ; Fri, 23 May 2003 06:28:19 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.009DEE12@cherry.ease.lsoft.com>; Fri, 23 May 2003 6:28:19 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 665852 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 23 May 2003 06:28:19 -0400 Received: from 203.199.83.32 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 23 May 2003 06:28:17 -0400 Received: (qmail 29749 invoked by uid 510); 23 May 2003 10:28:14 -0000 Received: from unknown (203.197.138.201) by rediffmail.com via HTTP; 23 may 2003 10:28:14 -0000 MIME-Version: 1.0 Content-type: text/plain; format=flowed Content-Disposition: inline Message-ID: <20030523102814.29748.qmail@webmail32.rediffmail.com> Date: Fri, 23 May 2003 10:28:14 -0000 Reply-To: Mailing List Sender: Mailing List From: Vivek Dubey Subject: OSPF Refresh and Flooding Reduction in Stable Topologies To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Padma, 1) Ospf LSA refreshing/aging provides robustness to protocol 2) Demand circuit proposed a special case compromising this robustness. 3) draft-pillay-esnault-ospf-flooding-05.txt : Proposes : "The flooding reduction capable routers will continue to send hellos to their neighbors and keep their aging self-originated LSAs in their database. However, they will flood their self-originated LSAs with the DoNotAge bit set. Hence, self-originated LSAs need not be reflooded unless there is change in the contents of the LSA. " Isn't the net effect is "do not age LSAs"....ways to do that could be (aim here is to Refresh and Flooding Reduction in Stable Topologies): 1)Either set DoNotAge bit (as above draft and RFC 1793 says) OR 2) a) Avoid the aging concept, ie dont do any flushing from database , if any LSA reaches maxage. Instead if LSA reaches maxAge , check as RFC 1793 says.. (1) The LSA has been in the router's database for at least MaxAge seconds. (2) The originator of the LSA has been unreachable (according to the routing calculations specified by Section 16 of [1]) for at least MaxAge seconds. Flush maxage LSA only if two above conditions are met. If not, probably reset the age to zero. b)As "draft-pillay-esnault-ospf-flooding-05.txt" says "self-originated LSAs need not be reflooded unless there is change in the contents of the LSA. " Wont point (2) will have same effect as setting "Do not age bit"..... Morevr one need not depend on demand circuit extension also.. There could be few other issues with point (2) but wanted to know comments of the group on the approach. thanks, vivek ___________________________________________________ Get email that means BUSINESS! me @ mycompany.com. Just Rs.1499/year. To start, click http://www.rediffmailpro.com From owner-ospf@PEACH.EASE.LSOFT.COM Fri May 23 13:57:19 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17323 for ; Fri, 23 May 2003 13:57:19 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.009DFF30@cherry.ease.lsoft.com>; Fri, 23 May 2003 13:57:17 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 43505682 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 23 May 2003 13:57:13 -0400 Received: from 209.119.0.109 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 23 May 2003 13:57:13 -0400 Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.009E006B@cherry.ease.lsoft.com>; Fri, 23 May 2003 13:57:13 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 23 May 2003 13:57:13 -0400 Received: from redback.com (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id 0B9CB61F4A3 for ; Fri, 23 May 2003 10:57:10 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <20030523102814.29748.qmail@webmail32.rediffmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3ECE60CE.9020809@redback.com> Date: Fri, 23 May 2003 13:56:30 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: OSPF Refresh and Flooding Reduction in Stable Topologies Comments: To: Mailing List To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Vivek, The draft relies on RFC 1793 and uses the same mechanisms. Other approachs are certainly possible. Thanks, Acee Vivek Dubey wrote: > Padma, > > 1) Ospf LSA refreshing/aging provides robustness > to protocol > > 2) Demand circuit proposed a special case > compromising this robustness. > > 3) draft-pillay-esnault-ospf-flooding-05.txt : > Proposes : > "The flooding reduction capable routers will continue to send > hellos > to their neighbors and keep their aging self-originated LSAs > in > their database. However, they will flood their self-originated > LSAs > with the DoNotAge bit set. Hence, self-originated LSAs need > not be > reflooded unless there is change in the contents of the LSA. > " > > Isn't the net effect is "do not age LSAs"....ways > to do that could be (aim here is to Refresh and Flooding > Reduction in Stable Topologies): > > 1)Either set DoNotAge bit (as above draft and RFC 1793 says) > OR > 2) > a) > Avoid the aging concept, ie dont do any > flushing from database , if any LSA reaches maxage. > > Instead if LSA reaches maxAge , check as RFC 1793 says.. > (1) The LSA has been in the router's database for at > least > MaxAge seconds. > > (2) The originator of the LSA has been unreachable > (according > to the routing calculations specified by Section 16 > of [1]) > for at least MaxAge seconds. > > Flush maxage LSA only if two above conditions are met. > If not, probably reset the age to zero. > > b)As "draft-pillay-esnault-ospf-flooding-05.txt" says > "self-originated LSAs need not be reflooded unless > there is change in the contents of the LSA. " > > Wont point (2) will have same effect as setting > "Do not age bit"..... > Morevr one need not depend on demand circuit extension > also.. > There could be few other issues with point (2) but wanted > to know comments of the group on the approach. > > thanks, > vivek > > > ___________________________________________________ > Get email that means BUSINESS! me @ mycompany.com. > Just Rs.1499/year. > To start, click http://www.rediffmailpro.com > -- Acee From owner-ospf@PEACH.EASE.LSOFT.COM Fri May 23 18:58:26 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29552 for ; Fri, 23 May 2003 18:58:26 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.009E083F@cherry.ease.lsoft.com>; Fri, 23 May 2003 18:58:27 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 43525561 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 23 May 2003 18:58:26 -0400 Received: from 209.119.0.109 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 23 May 2003 18:58:26 -0400 Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.009E06B1@cherry.ease.lsoft.com>; Fri, 23 May 2003 18:58:25 -0400 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 23 May 2003 18:58:25 -0400 Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h4NMwOu14818; Fri, 23 May 2003 15:58:24 -0700 (PDT) (envelope-from padma@juniper.net) Received: (from padma@localhost) by garnet.juniper.net (8.11.5/8.11.3) id h4NMwOT19314; Fri, 23 May 2003 15:58:24 -0700 (PDT) (envelope-from padma) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <200305232258.h4NMwOT19314@garnet.juniper.net> Date: Fri, 23 May 2003 15:58:24 -0700 Reply-To: Mailing List Sender: Mailing List From: Padma Pillay-Esnault Subject: Re: OSPF Refresh and Flooding Reduction in Stable Topologies Comments: To: OSPF@DISCUSS.MICROSOFT.COM To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <20030523102814.29748.qmail@webmail32.rediffmail.com> from "Vivek Dubey" at May 23, 2003 10:28:14 AM Precedence: list Content-Transfer-Encoding: 7bit Hi Vivek See comments below. > > Padma, > > 1) Ospf LSA refreshing/aging provides robustness > to protocol > Yes in theory. IMHO if we had a lot of cases where only refresh corrected malfunctions .. we would hear a lot of complaints that OSPF is malfunctioning within a 30 minutes window. > 2) Demand circuit proposed a special case > compromising this robustness. > see above > 3) draft-pillay-esnault-ospf-flooding-05.txt : > Proposes : > "The flooding reduction capable routers will continue to send > hellos > to their neighbors and keep their aging self-originated LSAs > in > their database. However, they will flood their self-originated > LSAs > with the DoNotAge bit set. Hence, self-originated LSAs need > not be > reflooded unless there is change in the contents of the LSA. > " > > Isn't the net effect is "do not age LSAs"....ways > to do that could be (aim here is to Refresh and Flooding > Reduction in Stable Topologies): > > 1)Either set DoNotAge bit (as above draft and RFC 1793 says) > OR > 2) > a) > Avoid the aging concept, ie dont do any > flushing from database , if any LSA reaches maxage. > > Instead if LSA reaches maxAge , check as RFC 1793 says.. > (1) The LSA has been in the router's database for at > least > MaxAge seconds. > > (2) The originator of the LSA has been unreachable > (according > to the routing calculations specified by Section 16 > of [1]) > for at least MaxAge seconds. > > Flush maxage LSA only if two above conditions are met. > If not, probably reset the age to zero. > > b)As "draft-pillay-esnault-ospf-flooding-05.txt" says > "self-originated LSAs need not be reflooded unless > there is change in the contents of the LSA. " > > Wont point (2) will have same effect as setting > "Do not age bit"..... > Morevr one need not depend on demand circuit extension > also.. > There could be few other issues with point (2) but wanted > to know comments of the group on the approach. There are major drawbacks to the approach in 2. 1. In the approach in (2) -- all routers will have to be upgraded to deploy the feature. The originating routers to block their flooding and the receiving routers implement no aging in DB. In the draft only some routers need to be upgraded to make the feature work as long as the receiving routers understand DNA lsas. 2. So the routers receiving will not age any LSAs that they received. By default I guess they will not age LSAs from *all* routers or else you will have to configure that on each receiving router. This is not very realistic. More over how will you know if there are routers out they that are aging their database and hence require the originating router to refresh ? All these cases are covered in the draft. - the originator controls the flooding and how its lsa should be treated by others. - Use of indication lsas enables the originating router to revert to normal flooding and DNA clear if a router does not implement the DNA within the AS. - No need to update all routers to get the feature working - Configuration is only on the originating routers with flooding reduction. Padma > > thanks, > vivek > > > ___________________________________________________ > Get email that means BUSINESS! me @ mycompany.com. > Just Rs.1499/year. > To start, click http://www.rediffmailpro.com > From owner-ospf@PEACH.EASE.LSOFT.COM Fri May 23 20:22:34 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01398 for ; Fri, 23 May 2003 20:22:34 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.009E078E@cherry.ease.lsoft.com>; Fri, 23 May 2003 20:22:33 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 43531938 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 23 May 2003 20:22:30 -0400 Received: from 32.97.110.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 23 May 2003 20:22:30 -0400 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e31.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h4O0MTQs249348 for ; Fri, 23 May 2003 20:22:29 -0400 Received: from d03nm118.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h4O0MS6C147904 for ; Fri, 23 May 2003 18:22:28 -0600 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 6.0.1 [IBM]|April 17, 2003) at 05/23/2003 18:22:28 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Message-ID: Date: Fri, 23 May 2003 18:22:26 -0600 Reply-To: Mailing List Sender: Mailing List From: Mike Fox Subject: Mike Fox/Raleigh/IBM is out of the office. To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list I will be out of the office starting May 23, 2003 and will not return until June 2, 2003. I will respond to your message when I return. From owner-ospf@PEACH.EASE.LSOFT.COM Mon May 26 22:24:58 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11691 for ; Mon, 26 May 2003 22:24:57 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.009E56CC@cherry.ease.lsoft.com>; Mon, 26 May 2003 22:24:56 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 43751943 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 26 May 2003 22:24:55 -0400 Received: from 209.119.0.109 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 26 May 2003 22:24:55 -0400 Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.009E5791@cherry.ease.lsoft.com>; Mon, 26 May 2003 22:24:55 -0400 Received: from 192.51.44.35 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 26 May 2003 22:24:55 -0400 Received: from m4.gw.fujitsu.co.jp ([10.0.50.74]) by fgwmail5.fujitsu.co.jp (8.12.9/Fujitsu Gateway) id h4R2OoQU015764 for ; Tue, 27 May 2003 11:24:50 +0900 (envelope-from sasaki@soft.net.fujitsu.co.jp) Received: from n5.gw.fujitsu.co.jp by m4.gw.fujitsu.co.jp (8.12.9/Fujitsu Domain Master) id h4R2L5aK009622 for ; Tue, 27 May 2003 11:24:50 +0900 (envelope-from sasaki@soft.net.fujitsu.co.jp) Received: from mailhost.soft.net.fujitsu.co.jp ([10.0.50.63]) by n5.gw.fujitsu.co.jp (SAVSMTP 3.0.0.44) with SMTP id M2003052711244916851 for ; Tue, 27 May 2003 11:24:49 +0900 Received: from [10.22.113.249] (dhcp113249.nd.net.fujitsu.co.jp [10.22.113.249]) by mailhost.soft.net.fujitsu.co.jp (8.12.9/8.12.9) with ESMTP id h4R2OnN2020158 for ; Tue, 27 May 2003 11:24:49 +0900 (JST) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.05.06 Message-ID: <20030527103605.5037.SASAKI@soft.net.fujitsu.co.jp> Date: Tue, 27 May 2003 11:24:49 +0900 Reply-To: Mailing List Sender: Mailing List From: Taisuke Sasaki Subject: OSPFv3 BadLSReq Comments: To: OSPF@DISCUSS.MICROSOFT.COM To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit I have a question about a OSPFv3 Database exchange process. Suppose below: 1) R1 has only 1 Broadcast interface in Area 0. R2 has 2 interfaces in Area 0. (one is a broadcast and the other is a loopback) 2) Both the R1's interface and the R2's are assigned the same IPv6 prefix (Prefix A). 3) At first, the link between R1 and R2 is down. 4) Consider about R1. +---+ Prefix A +---+ |R1 +------X------+R2 | +---+ +---+ When the link is up, R1 originates a Intra-Area-Prefix-LSA associated with a Router-LSA. This Intra-Area-Prefix-LSA has a Prefix A. In a database exchange process: when R1 receives the last Database Description packet from R2, neighbor event "ExchangeDone" happens and neighbor state transits to "Loading" or "Full" in R1. If the neighbor state transit to "Full", R1 flushes an Intra-Area-Prefix-LSA associate with a Router-LSA through premature aging process because it is thought that the interface turns to be adjacent. After the above event: When R1 receives a LS-Request packet from R2, it is possible that neighbor event "BadLSReq" happens in R1 because R2 told R1 in Database Description packets that I had an Intra-Area-Prefix-LSA associated with a Router-LSA . But now, R1 has already flushed it. --- taisuke sasaki From owner-ospf@PEACH.EASE.LSOFT.COM Tue May 27 09:29:32 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11022 for ; Tue, 27 May 2003 09:29:31 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.009E64B9@cherry.ease.lsoft.com>; Tue, 27 May 2003 9:29:31 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 43797562 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 27 May 2003 09:29:30 -0400 Received: from 209.119.0.100 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 27 May 2003 09:19:30 -0400 Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.009E65D6@cherry.ease.lsoft.com>; Tue, 27 May 2003 9:19:29 -0400 Received: from 209.202.99.50 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 27 May 2003 09:19:29 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Thread-Topic: Vendor attributes in TE LSAs Thread-Index: AcMkUpoR9ApzCbnqScOXd84yz5YGfA== Message-ID: <83040F98B407E6428FEC18AC720F5D73200F09@exchange.tropicnetworks.com> Date: Tue, 27 May 2003 09:19:28 -0400 Reply-To: Mailing List Sender: Mailing List From: Udo Neustadter Subject: Vendor attributes in TE LSAs Comments: To: ospf@discuss.microsoft.com Comments: cc: ccamp@ops.ietf.org To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA11022 Hi all, I am working on a GMPLS implementation, and part of my problem is the addition of company specific data to the TE LSAs. The Internet-Draft http://www.ietf.org/internet-drafts/draft-udo-ospf-vendatt-00.txt proposes an interoperable way to solve the following two issues: 1. Companies that already applied with IANA for an SMI Network management enterprise code do not need to re-apply for sub-TLV values from the pool of numbers reserved for private use 2. Allows private attributes/data to be embedded in the TE router LSA (the one TE LSA that contains the router address TLV). I would like for the draft to be considered part of this working group. This work is an extension to the work done in http://www.ietf.org/internet-drafts/draft-katz-yeung-ospf-traffic-09.txt and http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-gmpls-extensio ns-09.txt. Thanks in advance for your support. Udo From owner-ospf@PEACH.EASE.LSOFT.COM Tue May 27 12:39:07 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19176 for ; Tue, 27 May 2003 12:39:06 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.009E69F5@cherry.ease.lsoft.com>; Tue, 27 May 2003 12:39:07 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 43810475 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 27 May 2003 12:39:06 -0400 Received: from 144.189.100.106 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 27 May 2003 12:39:05 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id h4RGd4gZ018353 for ; Tue, 27 May 2003 09:39:05 -0700 (MST) Received: from xover.corp.mot.com (xover.corp.mot.com [10.1.148.18]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id h4RGd3Qx026242 for ; Tue, 27 May 2003 11:39:03 -0500 Received: by xover.corp.mot.com with Internet Mail Service (5.5.2653.19) id ; Tue, 27 May 2003 12:38:46 -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, 27 May 2003 12:40:40 -0400 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: Vendor attributes in TE LSAs To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Hi Udo, The draft looks pretty straight forward and simple. A similar draft exists in IS-IS http://www.ietf.org/internet-drafts/draft-ietf-isis-experimental-tlv-00.txt , and instead of "SMI Network management enterprise code for the vendor or organization" uses "a valid IEEE assigned OUI as the first three bytes of the value of the TLV." I do not know the tradeoffs but if possible we could use the same value too. Maybe someone could point out the tradeoffs if any. Besides I guess Section 5(if the same mechanism is used in TLV's) and Section 6 of the ISIS draft wold be valid here too. Thanks, Vishwas -----Original Message----- From: Udo Neustadter [mailto:neustadter@TROPICNETWORKS.COM] Sent: Tuesday, May 27, 2003 6:49 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Vendor attributes in TE LSAs Hi all, I am working on a GMPLS implementation, and part of my problem is the addition of company specific data to the TE LSAs. The Internet-Draft http://www.ietf.org/internet-drafts/draft-udo-ospf-vendatt-00.txt proposes an interoperable way to solve the following two issues: 1. Companies that already applied with IANA for an SMI Network management enterprise code do not need to re-apply for sub-TLV values from the pool of numbers reserved for private use 2. Allows private attributes/data to be embedded in the TE router LSA (the one TE LSA that contains the router address TLV). I would like for the draft to be considered part of this working group. This work is an extension to the work done in http://www.ietf.org/internet-drafts/draft-katz-yeung-ospf-traffic-09.txt and http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-gmpls-extensio ns-09.txt. Thanks in advance for your support. Udo From owner-ospf@PEACH.EASE.LSOFT.COM Tue May 27 13:46:36 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21278 for ; Tue, 27 May 2003 13:46:35 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.009E6B86@cherry.ease.lsoft.com>; Tue, 27 May 2003 13:46:32 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 43826121 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 27 May 2003 13:43:57 -0400 Received: from 24.93.67.82 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 27 May 2003 13:43:56 -0400 Received: from redback.com (cpe-024-211-135-117.nc.rr.com [24.211.135.117]) by ms-smtp-01.southeast.rr.com (8.12.5/8.12.2) with ESMTP id h4RHcesb006358 for ; Tue, 27 May 2003 13:38:41 -0400 (EDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <20030527103605.5037.SASAKI@soft.net.fujitsu.co.jp> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3ED3A37F.2050803@redback.com> Date: Tue, 27 May 2003 13:42:23 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: OSPFv3 BadLSReq To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Taisuke Sasaki wrote: > I have a question about a OSPFv3 Database exchange process. > > Suppose below: > 1) R1 has only 1 Broadcast interface in Area 0. > R2 has 2 interfaces in Area 0. > (one is a broadcast and the other is a loopback) > > 2) Both the R1's interface and the R2's are assigned > the same IPv6 prefix (Prefix A). > > 3) At first, the link between R1 and R2 is down. > > 4) Consider about R1. > > +---+ Prefix A +---+ > |R1 +------X------+R2 | > +---+ +---+ > > When the link is up, R1 originates a Intra-Area-Prefix-LSA > associated with a Router-LSA. > This Intra-Area-Prefix-LSA has a Prefix A. > > In a database exchange process: > when R1 receives the last Database Description packet from R2, > neighbor event "ExchangeDone" happens and neighbor state > transits to "Loading" or "Full" in R1. > > If the neighbor state transit to "Full", > R1 flushes an Intra-Area-Prefix-LSA associate with a Router-LSA > through premature aging process because it is thought that the > interface turns to be adjacent. > > After the above event: > When R1 receives a LS-Request packet from R2, > it is possible that neighbor event "BadLSReq" happens in R1 > because R2 told R1 in Database Description packets that > I had an Intra-Area-Prefix-LSA associated with a Router-LSA . > But now, R1 has already flushed it. > Hello Taisuke Sasaki, R2 should place the MaxAge LSA on neighbor R1's retransmission list when it flushes it. The LSA should not be removed from R2's link state database as long as there are routers in exchange or loading state. Refer to RFC 2328 section 14.1. Thanks, Acee -- Acee From owner-ospf@PEACH.EASE.LSOFT.COM Tue May 27 18:06:36 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04755 for ; Tue, 27 May 2003 18:06:36 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.009E7242@cherry.ease.lsoft.com>; Tue, 27 May 2003 18:06:36 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 43852731 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 27 May 2003 18:06:32 -0400 Received: from 209.119.0.109 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 27 May 2003 17:56:32 -0400 Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.009E7229@cherry.ease.lsoft.com>; Tue, 27 May 2003 17:56:32 -0400 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 27 May 2003 17:56:32 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04068; Tue, 27 May 2003 17:56:28 -0400 (EDT) Message-ID: <200305272156.RAA04068@ietf.org> Date: Tue, 27 May 2003 17:56:28 -0400 Reply-To: Mailing List Sender: Mailing List Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: The IESG Subject: Last Call: Detecting Inactive Neighbors over OSPF Demand Circuits to Proposed Standard Comments: cc: ospf@discuss.microsoft.com To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list The IESG has received a request from the Open Shortest Path First IGP Working Group to consider Detecting Inactive Neighbors over OSPF Demand Circuits as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2003-6-10. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ospf-dc-06.txt From owner-ospf@PEACH.EASE.LSOFT.COM Tue May 27 22:41:34 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15758 for ; Tue, 27 May 2003 22:41:34 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.009E77E6@cherry.ease.lsoft.com>; Tue, 27 May 2003 22:41:34 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 43877212 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 27 May 2003 22:41:31 -0400 Received: from 192.51.44.37 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 27 May 2003 22:41:31 -0400 Received: from m7.gw.fujitsu.co.jp ([10.0.50.77]) by fgwmail7.fujitsu.co.jp (8.12.9/Fujitsu Gateway) id h4S2fVM2028093 for ; Wed, 28 May 2003 11:41:31 +0900 (envelope-from sasaki@soft.net.fujitsu.co.jp) Received: from n2.gw.fujitsu.co.jp by m7.gw.fujitsu.co.jp (8.12.9/Fujitsu Domain Master) id h4S2eaaL005612 for ; Wed, 28 May 2003 11:41:31 +0900 (envelope-from sasaki@soft.net.fujitsu.co.jp) Received: from s2.gw.fujitsu.co.jp ([10.0.50.62]) by n2.gw.fujitsu.co.jp (SAVSMTP 3.0.0.44) with SMTP id M2003052811412816175 for ; Wed, 28 May 2003 11:41:28 +0900 Received: from mailhost.soft.net.fujitsu.co.jp (mailhost.soft.net.fujitsu.co.jp [10.22.111.128]) by s2.gw.fujitsu.co.jp (8.12.9) id h4S2fSZe028360 for ; Wed, 28 May 2003 11:41:28 +0900 (envelope-from sasaki@soft.net.fujitsu.co.jp) Received: from [10.22.113.249] (dhcp113249.nd.net.fujitsu.co.jp [10.22.113.249]) by mailhost.soft.net.fujitsu.co.jp (8.12.9/8.12.9) with ESMTP id h4S2fRN2003856 for ; Wed, 28 May 2003 11:41:27 +0900 (JST) References: <20030527103605.5037.SASAKI@soft.net.fujitsu.co.jp> <3ED3A37F.2050803@redback.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.05.06 Message-ID: <20030528094801.7A22.SASAKI@soft.net.fujitsu.co.jp> Date: Wed, 28 May 2003 11:41:26 +0900 Reply-To: Mailing List Sender: Mailing List From: Taisuke Sasaki Subject: Re: OSPFv3 BadLSReq To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <3ED3A37F.2050803@redback.com> Precedence: list Content-Transfer-Encoding: 7bit Hello Acee. Thank you for your reply. I had an error in writing in my previous mail. > Taisuke Sasaki wrote: > > I have a question about a OSPFv3 Database exchange process. > > > > Suppose below: > > 1) R1 has only 1 Broadcast interface in Area 0. > > R2 has 2 interfaces in Area 0. > > (one is a broadcast and the other is a loopback) > > > > 2) Both the R1's interface and the R2's are assigned > > the same IPv6 prefix (Prefix A). > > > > 3) At first, the link between R1 and R2 is down. > > > > 4) Consider about R1. > > > > +---+ Prefix A +---+ > > |R1 +------X------+R2 | > > +---+ +---+ > > > > When the link is up, R1 originates a Intra-Area-Prefix-LSA > > associated with a Router-LSA. > > This Intra-Area-Prefix-LSA has a Prefix A. > > > > In a database exchange process: > > when R1 receives the last Database Description packet from R2, > > neighbor event "ExchangeDone" happens and neighbor state > > transits to "Loading" or "Full" in R1. > > > > If the neighbor state transit to "Full", > > R1 flushes an Intra-Area-Prefix-LSA associate with a Router-LSA > > through premature aging process because it is thought that the > > interface turns to be adjacent. > > > > After the above event: > > When R1 receives a LS-Request packet from R2, > > it is possible that neighbor event "BadLSReq" happens in R1 > > because R2 told R1 in Database Description packets that > > I had an Intra-Area-Prefix-LSA associated with a Router-LSA . > > But now, R1 has already flushed it. > > When R1 receives a LS-Request packet from R2, it is possible that neighbor event "BadLSReq" happens in R1 because R1 told R2 in Database Description packets that ^^^^^^^^^^ I had an Intra-Area-Prefix-LSA associated with a Router-LSA . But now, R1 has already flushed it. > R2 should place the MaxAge LSA on neighbor R1's retransmission list > when it flushes it. The LSA should not be removed from R2's > link state database as long as there are routers in exchange or > loading state. Refer to RFC 2328 section 14.1. In R1, the LSA(Intra-Area-Prefix-LSA associated with a Router-LSA) was already flushed because R2's neighbor state is "FULL". There in no router in exchange or loading state. The point is below: 1) R1 told R2 that R1 had an Intra-Area-Prefix-LSA associated with a Router-LSA in Database Description packets. So, R2 will request the Intra-Area-Prefix-LSA. nevertheless, 2) When R1 receives a LS-Request packet from R2, it is possible that R2's neighbor state is already full, and there is no router in exchange or loading state, and an Intra-Area-Prefix-LSA associated with a Router-LSA is already flushed in R1's link state database. So, BadLSReq event will happen. --- taisuke sasaki From owner-ospf@PEACH.EASE.LSOFT.COM Tue May 27 23:23:30 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17180 for ; Tue, 27 May 2003 23:23:30 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.009E79CF@cherry.ease.lsoft.com>; Tue, 27 May 2003 23:23:31 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 43881672 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 27 May 2003 23:23:28 -0400 Received: from 24.93.67.82 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 27 May 2003 23:23:28 -0400 Received: from redback.com (rdu162-235-058.nc.rr.com [24.162.235.58]) by ms-smtp-01.southeast.rr.com (8.12.5/8.12.2) with ESMTP id h4S3ICsb001189 for ; Tue, 27 May 2003 23:18:13 -0400 (EDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <20030527103605.5037.SASAKI@soft.net.fujitsu.co.jp> <3ED3A37F.2050803@redback.com> <20030528094801.7A22.SASAKI@soft.net.fujitsu.co.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3ED42B4F.2080906@redback.com> Date: Tue, 27 May 2003 23:21:51 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: OSPFv3 BadLSReq To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hello Taisuke Sasaki, Maybe I am missing your scenario. See below. Taisuke Sasaki wrote: > Hello Acee. > Thank you for your reply. > > I had an error in writing in my previous mail. > > >>Taisuke Sasaki wrote: >> >>>I have a question about a OSPFv3 Database exchange process. >>> >>>Suppose below: >>>1) R1 has only 1 Broadcast interface in Area 0. >>> R2 has 2 interfaces in Area 0. >>> (one is a broadcast and the other is a loopback) >>> >>>2) Both the R1's interface and the R2's are assigned >>> the same IPv6 prefix (Prefix A). >>> >>>3) At first, the link between R1 and R2 is down. >>> >>>4) Consider about R1. >>> >>> +---+ Prefix A +---+ >>> |R1 +------X------+R2 | >>> +---+ +---+ >>> >>>When the link is up, R1 originates a Intra-Area-Prefix-LSA >>>associated with a Router-LSA. >>>This Intra-Area-Prefix-LSA has a Prefix A. >>> >>>In a database exchange process: >>>when R1 receives the last Database Description packet from R2, >>>neighbor event "ExchangeDone" happens and neighbor state >>>transits to "Loading" or "Full" in R1. >>> >>>If the neighbor state transit to "Full", >>>R1 flushes an Intra-Area-Prefix-LSA associate with a Router-LSA >>>through premature aging process because it is thought that the >>>interface turns to be adjacent. >>> >>>After the above event: >>>When R1 receives a LS-Request packet from R2, >>>it is possible that neighbor event "BadLSReq" happens in R1 >>>because R2 told R1 in Database Description packets that >>>I had an Intra-Area-Prefix-LSA associated with a Router-LSA . >>>But now, R1 has already flushed it. >>> >> > > When R1 receives a LS-Request packet from R2, > it is possible that neighbor event "BadLSReq" happens in R1 > because R1 told R2 in Database Description packets that > ^^^^^^^^^^ > I had an Intra-Area-Prefix-LSA associated with a Router-LSA . > But now, R1 has already flushed it. > > > >>R2 should place the MaxAge LSA on neighbor R1's retransmission list >>when it flushes it. The LSA should not be removed from R2's >>link state database as long as there are routers in exchange or >>loading state. Refer to RFC 2328 section 14.1. > > > In R1, the LSA(Intra-Area-Prefix-LSA associated with a Router-LSA) > was already flushed because R2's neighbor state is "FULL". > There in no router in exchange or loading state. Then how can there be a LS Request packet if neither router is in exchange/loading state? > > The point is below: > 1) R1 told R2 that R1 had an Intra-Area-Prefix-LSA associated > with a Router-LSA in Database Description packets. > So, R2 will request the Intra-Area-Prefix-LSA. The reference LSA in the intra-area prefix LSA should not be examined in the database exchange process. Each LSA should be considered synchronized individually. > > nevertheless, > > 2) When R1 receives a LS-Request packet from R2, > it is possible that R2's neighbor state is already full, > and there is no router in exchange or loading state, Nope - A router will only send a LS-Request packet in exchange/loading state. > and an Intra-Area-Prefix-LSA associated with a Router-LSA > is already flushed in R1's link state database. > So, BadLSReq event will happen. > > --- > taisuke sasaki > -- Acee From owner-ospf@PEACH.EASE.LSOFT.COM Wed May 28 00:20:41 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18883 for ; Wed, 28 May 2003 00:20:40 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.009E806D@cherry.ease.lsoft.com>; Wed, 28 May 2003 0:20:41 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 43895296 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 28 May 2003 00:20:38 -0400 Received: from 24.93.67.82 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 28 May 2003 00:20:38 -0400 Received: from redback.com (rdu162-235-058.nc.rr.com [24.162.235.58]) by ms-smtp-01.southeast.rr.com (8.12.5/8.12.2) with ESMTP id h4S4FNsb026636 for ; Wed, 28 May 2003 00:15:23 -0400 (EDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <83040F98B407E6428FEC18AC720F5D73200F09@exchange.tropicnetworks.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3ED438B5.1070000@redback.com> Date: Wed, 28 May 2003 00:19:01 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Vendor attributes in TE LSAs To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Udo, I don't support this enhancement since it essentially removes any Udo Neustadter wrote: > Hi all, > > I am working on a GMPLS implementation, and part of my problem is the > addition of company specific data to the TE LSAs. The Internet-Draft > http://www.ietf.org/internet-drafts/draft-udo-ospf-vendatt-00.txt > proposes an interoperable way to solve the following two issues: > 1. Companies that already applied with IANA for an SMI Network > management enterprise code do not need to re-apply for sub-TLV values > from the pool of numbers reserved for private use > 2. Allows private attributes/data to be embedded in the TE router LSA > (the one TE LSA that contains the router address TLV). > > I would like for the draft to be considered part of this working group. > This work is an extension to the work done in > http://www.ietf.org/internet-drafts/draft-katz-yeung-ospf-traffic-09.txt > and > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-gmpls-extensio > ns-09.txt. > > Thanks in advance for your support. > > Udo > -- Acee From owner-ospf@PEACH.EASE.LSOFT.COM Wed May 28 00:39:04 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19972 for ; Wed, 28 May 2003 00:39:03 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.009E806F@cherry.ease.lsoft.com>; Wed, 28 May 2003 0:39:05 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 43898909 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 28 May 2003 00:39:03 -0400 Received: from 24.93.67.84 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 28 May 2003 00:39:03 -0400 Received: from redback.com (rdu162-235-058.nc.rr.com [24.162.235.58]) by ms-smtp-03.southeast.rr.com (8.12.5/8.12.2) with ESMTP id h4S4bTZo024510 for ; Wed, 28 May 2003 00:37:29 -0400 (EDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 Message-ID: <3ED43D05.20902@redback.com> Date: Wed, 28 May 2003 00:37:25 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Vendor attributes in TE LSAs - (Sent first reply prematurely) To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list References: <83040F98B407E6428FEC18AC720F5D73200F09@exchange.tropicnetworks.com> <3ED438B5.1070000@redback.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Udo, Aside from any technical details, I don't agree with this draft philosophically. In essence, it is a proposal to standardise on a mechanism to be non-standard. More specifically, it removes the OSPF WG, TE WG, and IETF in general from reviewing the vendor specific TLVs. The contents, size, and refresh rate of these TLVs are unknown. By definition, there is no interoperability. The same set of problems will undoubtedly be solved in multiple ways by different vendors using different vendor specific TLV encodings. Acee Lindem wrote: > Udo, > > I don't support this enhancement since it essentially removes any > > > Udo Neustadter wrote: > >> Hi all, >> >> I am working on a GMPLS implementation, and part of my problem is the >> addition of company specific data to the TE LSAs. The Internet-Draft >> http://www.ietf.org/internet-drafts/draft-udo-ospf-vendatt-00.txt >> proposes an interoperable way to solve the following two issues: >> 1. Companies that already applied with IANA for an SMI Network >> management enterprise code do not need to re-apply for sub-TLV values >> from the pool of numbers reserved for private use >> 2. Allows private attributes/data to be embedded in the TE router LSA >> (the one TE LSA that contains the router address TLV). >> >> I would like for the draft to be considered part of this working group. >> This work is an extension to the work done in >> http://www.ietf.org/internet-drafts/draft-katz-yeung-ospf-traffic-09.txt >> and >> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-gmpls-extensio >> ns-09.txt. >> >> Thanks in advance for your support. >> >> Udo >> > > > -- > Acee > -- Acee From owner-ospf@PEACH.EASE.LSOFT.COM Wed May 28 01:31:53 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21561 for ; Wed, 28 May 2003 01:31:52 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.009E838A@cherry.ease.lsoft.com>; Wed, 28 May 2003 1:31:51 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 43902967 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 28 May 2003 01:31:45 -0400 Received: from 24.93.67.84 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 28 May 2003 01:31:44 -0400 Received: from redback.com (rdu162-235-058.nc.rr.com [24.162.235.58]) by ms-smtp-03.southeast.rr.com (8.12.5/8.12.2) with ESMTP id h4S5UBZo013754 for ; Wed, 28 May 2003 01:30:12 -0400 (EDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3ED4495F.4050105@redback.com> Date: Wed, 28 May 2003 01:30:07 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: OSPF Capabilities Draft To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit The draft draft-raggarwal-igp-cap-0x.txt has been discussed at the last three IETFs. At the last two IETFs, there was mild support and we agreed to take the discussion to the OSPF WG list. In order to remove one of the barriers to making this draft a WG document, I have split out the OSPF specific portion into a separate draft. Rahul has done the same for ISIS. I beleive the time has come to accept this as a WG document. The described mechanism is consistent with other OSPF features and is backward compatible. All the OSPF options been have been allocated and new proposal will be able to make use of this mechanism without solving the option bit problem. One example is draft-vasseur-mpls-ospf-te-cap-00.txt. Link to draft below: http://www.ietf.org/internet-drafts/draft-lindem-ospf-cap-00.txt Further discussion? Any opposition to accepting this draft as a WG document? Thanks, -- Acee From owner-ospf@PEACH.EASE.LSOFT.COM Wed May 28 01:33:24 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21667 for ; Wed, 28 May 2003 01:33:24 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.009E81AB@cherry.ease.lsoft.com>; Wed, 28 May 2003 1:32:55 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 43903158 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 28 May 2003 01:32:52 -0400 Received: from 192.51.44.36 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 28 May 2003 01:32:51 -0400 Received: from m1.gw.fujitsu.co.jp ([10.0.50.71]) by fgwmail6.fujitsu.co.jp (8.12.9/Fujitsu Gateway) id h4S5WoLh030967 for ; Wed, 28 May 2003 14:32:50 +0900 (envelope-from sasaki@soft.net.fujitsu.co.jp) Received: from n5.gw.fujitsu.co.jp by m1.gw.fujitsu.co.jp (8.12.9/Fujitsu Domain Master) id h4S5WixH014654 for ; Wed, 28 May 2003 14:32:50 +0900 (envelope-from sasaki@soft.net.fujitsu.co.jp) Received: from s2.gw.fujitsu.co.jp ([10.0.50.61]) by n5.gw.fujitsu.co.jp (SAVSMTP 3.0.0.44) with SMTP id M2003052814324906386 for ; Wed, 28 May 2003 14:32:49 +0900 Received: from mailhost.soft.net.fujitsu.co.jp (mailhost.soft.net.fujitsu.co.jp [10.22.111.128]) by s2.gw.fujitsu.co.jp (8.12.9) id h4S5WnZe029510 for ; Wed, 28 May 2003 14:32:49 +0900 (envelope-from sasaki@soft.net.fujitsu.co.jp) Received: from [10.22.113.249] (dhcp113249.nd.net.fujitsu.co.jp [10.22.113.249]) by mailhost.soft.net.fujitsu.co.jp (8.12.9/8.12.9) with ESMTP id h4S5WnN2011728 for ; Wed, 28 May 2003 14:32:49 +0900 (JST) References: <20030528094801.7A22.SASAKI@soft.net.fujitsu.co.jp> <3ED42B4F.2080906@redback.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.05.06 Message-ID: <20030528132935.7A2A.SASAKI@soft.net.fujitsu.co.jp> Date: Wed, 28 May 2003 14:32:49 +0900 Reply-To: Mailing List Sender: Mailing List From: Taisuke Sasaki Subject: Re: OSPFv3 BadLSReq To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <3ED42B4F.2080906@redback.com> Precedence: list Content-Transfer-Encoding: 7bit > Hello Taisuke Sasaki, > > Maybe I am missing your scenario. See below. > > Taisuke Sasaki wrote: > > Hello Acee. > > Thank you for your reply. > > > > I had an error in writing in my previous mail. > > > > > >>Taisuke Sasaki wrote: > >> > >>>I have a question about a OSPFv3 Database exchange process. > >>> > >>>Suppose below: > >>>1) R1 has only 1 Broadcast interface in Area 0. > >>> R2 has 2 interfaces in Area 0. > >>> (one is a broadcast and the other is a loopback) > >>> > >>>2) Both the R1's interface and the R2's are assigned > >>> the same IPv6 prefix (Prefix A). > >>> > >>>3) At first, the link between R1 and R2 is down. > >>> > >>>4) Consider about R1. > >>> > >>> +---+ Prefix A +---+ > >>> |R1 +------X------+R2 | > >>> +---+ +---+ > >>> > >>>When the link is up, R1 originates a Intra-Area-Prefix-LSA > >>>associated with a Router-LSA. > >>>This Intra-Area-Prefix-LSA has a Prefix A. > >>> > >>>In a database exchange process: > >>>when R1 receives the last Database Description packet from R2, > >>>neighbor event "ExchangeDone" happens and neighbor state > >>>transits to "Loading" or "Full" in R1. > >>> > >>>If the neighbor state transit to "Full", > >>>R1 flushes an Intra-Area-Prefix-LSA associate with a Router-LSA > >>>through premature aging process because it is thought that the > >>>interface turns to be adjacent. > >>> > >>>After the above event: > >>>When R1 receives a LS-Request packet from R2, > >>>it is possible that neighbor event "BadLSReq" happens in R1 > >>>because R2 told R1 in Database Description packets that > >>>I had an Intra-Area-Prefix-LSA associated with a Router-LSA . > >>>But now, R1 has already flushed it. > >>> > >> > > > > When R1 receives a LS-Request packet from R2, > > it is possible that neighbor event "BadLSReq" happens in R1 > > because R1 told R2 in Database Description packets that > > ^^^^^^^^^^ > > I had an Intra-Area-Prefix-LSA associated with a Router-LSA . > > But now, R1 has already flushed it. > > > > > > > >>R2 should place the MaxAge LSA on neighbor R1's retransmission list > >>when it flushes it. The LSA should not be removed from R2's > >>link state database as long as there are routers in exchange or > >>loading state. Refer to RFC 2328 section 14.1. > > > > > > In R1, the LSA(Intra-Area-Prefix-LSA associated with a Router-LSA) > > was already flushed because R2's neighbor state is "FULL". > > There in no router in exchange or loading state. > > Then how can there be a LS Request packet if neither router is in > exchange/loading state? Please see my last comments. > > > > > The point is below: > > 1) R1 told R2 that R1 had an Intra-Area-Prefix-LSA associated > > with a Router-LSA in Database Description packets. > > So, R2 will request the Intra-Area-Prefix-LSA. > > The reference LSA in the intra-area prefix LSA should not be > examined in the database exchange process. Each LSA should > be considered synchronized individually. What I call "an Intra-Area-Prefix-LSA associated with a Router-LSA" is not what you call "a reference LSA", but a Intra-Area-Prefix-LSA to advertise its own prefixes and those of its attached stub links. (namely, an Intra-Area-Prefix-LSA which Referenced LS type is 0x2001) > > > > > nevertheless, > > > > 2) When R1 receives a LS-Request packet from R2, > > it is possible that R2's neighbor state is already full, > > and there is no router in exchange or loading state, > > Nope - A router will only send a LS-Request packet in > exchange/loading state. Indeed a router will only send a LS-Request packet in exchange/loading state, but a router does not necessarily receive a LS-Request packet in exchange/loading state. ^^^^^^^ My opinion is that a router can receive a LS-Request packet from the full state neighbor. example: +---+ +---+ |R1 |----------------|R2 | +---+ +---+ When R2 send a LS-Request packet: 1) from R2's point of view, R1's neighbor state is indeed exchange or loading. 2) from R1's point of view, R2's neighbor state can be exchange or loading or full. regards. --- taisuke sasaki From owner-ospf@PEACH.EASE.LSOFT.COM Wed May 28 01:34:42 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21733 for ; Wed, 28 May 2003 01:34:42 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.009E81AD@cherry.ease.lsoft.com>; Wed, 28 May 2003 1:34:41 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 43904669 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 28 May 2003 01:34:38 -0400 Received: from 144.189.100.105 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 28 May 2003 01:34:38 -0400 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate5.mot.com (Motorola/Motgate5) with ESMTP id h4S5Ycfj022731 for ; Tue, 27 May 2003 22:34:38 -0700 (MST) Received: from xover.corp.mot.com (xover.corp.mot.com [10.1.148.18]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id h4S5Ya2J006529 for ; Wed, 28 May 2003 00:34:37 -0500 Received: by xover.corp.mot.com with Internet Mail Service (5.5.2653.19) id ; Wed, 28 May 2003 01:34:20 -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, 28 May 2003 01:36:14 -0400 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: Vendor attributes in TE LSAs - (Sent first reply prematurely) To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Hi Acee, Though you can have vendor specific TLV encodings, the issue is there may be a clash in the TLV or Sub-TLV values. By using an SMI enterprise code or OUI to distinguish between various vendor specific implementations, we have one value that can be used by vendors instead of taking any TLV values, and we do not confuse information by various vendors, which are used for different purposes. Thanks, Vishwas -----Original Message----- From: Acee Lindem [mailto:acee@REDBACK.COM] Sent: Wednesday, May 28, 2003 10:07 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: Vendor attributes in TE LSAs - (Sent first reply prematurely) References: <83040F98B407E6428FEC18AC720F5D73200F09@exchange.tropicnetworks.com> <3ED438B5.1070000@redback.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Udo, Aside from any technical details, I don't agree with this draft philosophically. In essence, it is a proposal to standardise on a mechanism to be non-standard. More specifically, it removes the OSPF WG, TE WG, and IETF in general from reviewing the vendor specific TLVs. The contents, size, and refresh rate of these TLVs are unknown. By definition, there is no interoperability. The same set of problems will undoubtedly be solved in multiple ways by different vendors using different vendor specific TLV encodings. Acee Lindem wrote: > Udo, > > I don't support this enhancement since it essentially removes any > > > Udo Neustadter wrote: > >> Hi all, >> >> I am working on a GMPLS implementation, and part of my problem is the >> addition of company specific data to the TE LSAs. The Internet-Draft >> http://www.ietf.org/internet-drafts/draft-udo-ospf-vendatt-00.txt >> proposes an interoperable way to solve the following two issues: >> 1. Companies that already applied with IANA for an SMI Network >> management enterprise code do not need to re-apply for sub-TLV values >> from the pool of numbers reserved for private use >> 2. Allows private attributes/data to be embedded in the TE router LSA >> (the one TE LSA that contains the router address TLV). >> >> I would like for the draft to be considered part of this working group. >> This work is an extension to the work done in >> http://www.ietf.org/internet-drafts/draft-katz-yeung-ospf-traffic-09.txt >> and >> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-gmpls-extensio >> ns-09.txt. >> >> Thanks in advance for your support. >> >> Udo >> > > > -- > Acee > -- Acee From owner-ospf@PEACH.EASE.LSOFT.COM Wed May 28 02:47:05 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19061 for ; Wed, 28 May 2003 02:46:58 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.009E842F@cherry.ease.lsoft.com>; Wed, 28 May 2003 2:46:54 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 43910979 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 28 May 2003 02:46:51 -0400 Received: from 171.68.227.73 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 28 May 2003 02:46:51 -0400 Received: from smirtoraw2k03 (sjc-vpn1-381.cisco.com [10.21.97.125]) by fire.cisco.com (8.11.6+Sun/8.8.8) with ESMTP id h4S6ko024160 for ; Tue, 27 May 2003 23:46:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Message-ID: <010f01c324e4$ea504b60$386545ab@amer.cisco.com> Date: Tue, 27 May 2003 23:46:49 -0700 Reply-To: Mailing List Sender: Mailing List From: Sina Mirtorabi Subject: Re: OSPFv3 BadLSReq To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <20030528094801.7A22.SASAKI@soft.net.fujitsu.co.jp> Precedence: list Content-Transfer-Encoding: 7bit Taisuke -> The point is below: -> 1) R1 told R2 that R1 had an Intra-Area-Prefix-LSA associated -> with a Router-LSA in Database Description packets. -> So, R2 will request the Intra-Area-Prefix-LSA. -> -> nevertheless, -> -> 2) When R1 receives a LS-Request packet from R2, -> it is possible that R2's neighbor state is already full, I guess you meant to say "R1's neighbor state is already Full" -> and there is no router in exchange or loading state, -> and an Intra-Area-Prefix-LSA associated with a Router-LSA -> is already flushed in R1's link state database. -> So, BadLSReq event will happen. The point that you missed is that when R1 maxage its LSA it is expecting to get an Ack and when R2 receive the Maxage LSA it will remove it from its link state request list ( a part from sending an Ack ) -- From 2328 (b) Else, if the adjacency is not yet full (neighbor state is Exchange or Loading), examine the Link state request list associated with this adjacency. If there is an instance of the new LSA on the list, it indicates that the neighboring router has an instance of the LSA already. Compare the new LSA to the neighbor's copy: o If the new LSA is less recent, then examine the next neighbor. o If the two copies are the same instance, then delete the LSA from the Link state request list, and examine the next neighbor.[20] o Else, the new LSA is more recent. Delete the LSA from the Link state request list. -- Sina -> -> --- -> taisuke sasaki -> From owner-ospf@PEACH.EASE.LSOFT.COM Wed May 28 04:05:42 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20382 for ; Wed, 28 May 2003 04:05:42 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.009E85B4@cherry.ease.lsoft.com>; Wed, 28 May 2003 4:05:41 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 43911811 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 28 May 2003 04:05:39 -0400 Received: from 192.51.44.35 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 28 May 2003 04:05:38 -0400 Received: from m3.gw.fujitsu.co.jp ([10.0.50.73]) by fgwmail5.fujitsu.co.jp (8.12.9/Fujitsu Gateway) id h4S85XQU029616 for ; Wed, 28 May 2003 17:05:33 +0900 (envelope-from sasaki@soft.net.fujitsu.co.jp) Received: from n5.gw.fujitsu.co.jp by m3.gw.fujitsu.co.jp (8.12.9/Fujitsu Domain Master) id h4S7u18i011122 for ; Wed, 28 May 2003 17:05:33 +0900 (envelope-from sasaki@soft.net.fujitsu.co.jp) Received: from s2.gw.fujitsu.co.jp ([10.0.50.62]) by n5.gw.fujitsu.co.jp (SAVSMTP 3.0.0.44) with SMTP id M2003052817053231398 for ; Wed, 28 May 2003 17:05:33 +0900 Received: from mailhost.soft.net.fujitsu.co.jp (mailhost.soft.net.fujitsu.co.jp [10.22.111.128]) by s2.gw.fujitsu.co.jp (8.12.9) id h4S85WZe032075 for ; Wed, 28 May 2003 17:05:32 +0900 (envelope-from sasaki@soft.net.fujitsu.co.jp) Received: from [10.22.113.249] (dhcp113249.nd.net.fujitsu.co.jp [10.22.113.249]) by mailhost.soft.net.fujitsu.co.jp (8.12.9/8.12.9) with ESMTP id h4S85VN2018685 for ; Wed, 28 May 2003 17:05:31 +0900 (JST) References: <20030528094801.7A22.SASAKI@soft.net.fujitsu.co.jp> <010f01c324e4$ea504b60$386545ab@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.05.06 Message-ID: <20030528161250.7A2C.SASAKI@soft.net.fujitsu.co.jp> Date: Wed, 28 May 2003 17:05:31 +0900 Reply-To: Mailing List Sender: Mailing List From: Taisuke Sasaki Subject: Re: OSPFv3 BadLSReq To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <010f01c324e4$ea504b60$386545ab@amer.cisco.com> Precedence: list Content-Transfer-Encoding: 7bit Acee and Sina, Thank you for your detailed explanation. I read a rfc2328 14.1 again and carefully. Acee said: > R2 should place the MaxAge LSA on neighbor R1's retransmission list > when it flushes it. The LSA should not be removed from R2's > link state database as long as there are routers in exchange or > loading state. Refer to RFC 2328 section 14.1. Now, I understand that OSPF prevent R1 from BadLSReq event from the next 2 important points. right? R1) The premature aging process guarantees that MaxAge LSA is never flushed from its link state database as long as it is contained on any neighbor LS-Retransmission list. (this is what Acee pointed out) R2) Receiving R1's MaxAge LSA makes R2 delete the same instance of the LSA from the LS-Request list associated with R1, if needed. (this is what Sina pointed out) +---+ +---+ |R1 |----------------|R2 | +---+ +---+ > Taisuke > > -> The point is below: > -> 1) R1 told R2 that R1 had an Intra-Area-Prefix-LSA associated > -> with a Router-LSA in Database Description packets. > -> So, R2 will request the Intra-Area-Prefix-LSA. > -> > -> nevertheless, > -> > -> 2) When R1 receives a LS-Request packet from R2, > -> it is possible that R2's neighbor state is already full, > > I guess you meant to say "R1's neighbor state is already Full" > > -> and there is no router in exchange or loading state, > -> and an Intra-Area-Prefix-LSA associated with a Router-LSA > -> is already flushed in R1's link state database. > -> So, BadLSReq event will happen. > > The point that you missed is that when R1 maxage its LSA it is expecting > to get an Ack and when R2 receive the Maxage LSA it will remove it from > its link state request list ( a part from sending an Ack ) > > -- > > From 2328 > > (b) Else, if the adjacency is not yet full (neighbor state > is Exchange or Loading), examine the Link state request > list associated with this adjacency. If there is an > instance of the new LSA on the list, it indicates that > the neighboring router has an instance of the LSA > already. Compare the new LSA to the neighbor's copy: > > o If the new LSA is less recent, then examine the next > neighbor. > > o If the two copies are the same instance, then delete > the LSA from the Link state request list, and > examine the next neighbor.[20] > > o Else, the new LSA is more recent. Delete the LSA > from the Link state request list. > -- > > > Sina --- taisuke sasaki From owner-ospf@PEACH.EASE.LSOFT.COM Wed May 28 09:36:33 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02787 for ; Wed, 28 May 2003 09:36:33 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.009E8A86@cherry.ease.lsoft.com>; Wed, 28 May 2003 9:36:32 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 43935461 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 28 May 2003 09:36:29 -0400 Received: from 24.93.67.84 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 28 May 2003 09:36:29 -0400 Received: from redback.com (rdu26-55-006.nc.rr.com [66.26.55.6]) by ms-smtp-03.southeast.rr.com (8.12.5/8.12.2) with ESMTP id h4SDYuZo009147 for ; Wed, 28 May 2003 09:34:56 -0400 (EDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3ED4BAF6.3000804@redback.com> Date: Wed, 28 May 2003 09:34:46 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Vendor attributes in TE LSAs - (Sent first reply prematurely) To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Manral, Vishwas wrote: > Hi Acee, > > Though you can have vendor specific TLV encodings, the issue is there may be > a clash in the TLV or Sub-TLV values. > > By using an SMI enterprise code or OUI to distinguish between various vendor > specific implementations, we have one value that can be used by vendors > instead of taking any TLV values, and we do not confuse information by > various vendors, which are used for different purposes. Hi Vishwas, I understood the motivation. I think the SMI enterprise code is a better choice than the OUI since it is administered by IANA. However, I'm against the basic premise of allowing every vendor to roll their own TE LSAs and carry them in OSPF. I believe doing so could impact 1) Interoperability (there isn't any) 2) Scalability (LSA contents, size, and refresh frequency are unknown) and 3) Deployment - Debugging a multi-vendor network with many different vendor specific LSAs will be difficult. Thanks, Acee > > Thanks, > Vishwas > > -----Original Message----- > From: Acee Lindem [mailto:acee@REDBACK.COM] > Sent: Wednesday, May 28, 2003 10:07 AM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Re: Vendor attributes in TE LSAs - (Sent first reply > prematurely) > > > References: > <83040F98B407E6428FEC18AC720F5D73200F09@exchange.tropicnetworks.com> > <3ED438B5.1070000@redback.com> > Content-Type: text/plain; charset=us-ascii; format=flowed > Content-Transfer-Encoding: 7bit > > Udo, > > Aside from any technical details, I don't agree with this draft > philosophically. In essence, it is a proposal to standardise on > a mechanism to be non-standard. More specifically, it removes > the OSPF WG, TE WG, and IETF in general from reviewing the vendor > specific TLVs. The contents, size, and refresh rate of these TLVs > are unknown. > > By definition, there is no interoperability. The same set of problems > will undoubtedly be solved in multiple ways by different vendors using > different vendor specific TLV encodings. > > Acee Lindem wrote: > >>Udo, >> >>I don't support this enhancement since it essentially removes any >> >> >>Udo Neustadter wrote: >> >> >>>Hi all, >>> >>>I am working on a GMPLS implementation, and part of my problem is the >>>addition of company specific data to the TE LSAs. The Internet-Draft >>>http://www.ietf.org/internet-drafts/draft-udo-ospf-vendatt-00.txt >>>proposes an interoperable way to solve the following two issues: >>> 1. Companies that already applied with IANA for an SMI Network >>>management enterprise code do not need to re-apply for sub-TLV values >>>from the pool of numbers reserved for private use >>> 2. Allows private attributes/data to be embedded in the TE router LSA >>>(the one TE LSA that contains the router address TLV). >>> >>>I would like for the draft to be considered part of this working group. >>>This work is an extension to the work done in >>>http://www.ietf.org/internet-drafts/draft-katz-yeung-ospf-traffic-09.txt >>>and >>>http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-gmpls-extensio >>>ns-09.txt. >>> >>>Thanks in advance for your support. >>> >>>Udo >>> >> >> >>-- >>Acee >> > > > > -- > Acee > -- Acee From owner-ospf@PEACH.EASE.LSOFT.COM Wed May 28 09:39:38 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02893 for ; Wed, 28 May 2003 09:39:38 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.009E891F@cherry.ease.lsoft.com>; Wed, 28 May 2003 9:39:37 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 43935557 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 28 May 2003 09:39:35 -0400 Received: from 64.115.125.242 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 28 May 2003 09:39:35 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Wed, 28 May 2003 09:39:33 -0400 Reply-To: Mailing List Sender: Mailing List From: Jeff Parker Subject: Re: Vendor attributes in TE LSAs - (Sent first reply prematurely) To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Vishwas - I don't see anyone saying that there will be confusion about who "owns" a subtlv. I think the issue is that if company X devises a way to convey, say, stoats and weasels in a TLV, and company B devises a way to convey weasels and ferrets, we will not have a way for the weasels to interoperate. All of this will be done under the wraps, and the IETF and WG will never get a chance to point out that the ferret scheme doesn't scale, or that there is already a way to convey stoats, or that maybe weasels don't belong in an IGP: perhaps due to "size, and refresh rate" type of issues. - jeff parker > Hi Acee, > > Though you can have vendor specific TLV encodings, the > issue is there may be a clash in the TLV or Sub-TLV values. > > By using an SMI enterprise code or OUI to distinguish > between various vendor specific implementations, we > have one value that can be used by vendors instead of > taking any TLV values, and we do not confuse information > by various vendors, which are used for different purposes. > > Thanks, > Vishwas > > -----Original Message----- > From: Acee Lindem [mailto:acee@REDBACK.COM] > > Aside from any technical details, I don't agree with this draft > philosophically. In essence, it is a proposal to standardise on > a mechanism to be non-standard. More specifically, it removes > the OSPF WG, TE WG, and IETF in general from reviewing the vendor > specific TLVs. The contents, size, and refresh rate of these TLVs > are unknown. > > By definition, there is no interoperability. The same set of problems > will undoubtedly be solved in multiple ways by different vendors using > different vendor specific TLV encodings. > > Acee From owner-ospf@PEACH.EASE.LSOFT.COM Wed May 28 09:55:30 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03429 for ; Wed, 28 May 2003 09:55:29 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.009E8983@cherry.ease.lsoft.com>; Wed, 28 May 2003 9:55:29 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 43935948 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 28 May 2003 09:55:26 -0400 Received: from 24.93.67.82 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 28 May 2003 09:55:26 -0400 Received: from redback.com (rdu26-55-006.nc.rr.com [66.26.55.6]) by ms-smtp-01.southeast.rr.com (8.12.5/8.12.2) with ESMTP id h4SDoBsb028019 for ; Wed, 28 May 2003 09:50:12 -0400 (EDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <20030528094801.7A22.SASAKI@soft.net.fujitsu.co.jp> <010f01c324e4$ea504b60$386545ab@amer.cisco.com> <20030528161250.7A2C.SASAKI@soft.net.fujitsu.co.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3ED4BF67.9090300@redback.com> Date: Wed, 28 May 2003 09:53:43 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: OSPFv3 BadLSReq To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Taisuke Sasaki wrote: > Acee and Sina, > > Thank you for your detailed explanation. > I read a rfc2328 14.1 again and carefully. > > Acee said: > >>R2 should place the MaxAge LSA on neighbor R1's retransmission list >>when it flushes it. The LSA should not be removed from R2's >>link state database as long as there are routers in exchange or >>loading state. Refer to RFC 2328 section 14.1. > > > Now, I understand that OSPF prevent R1 from BadLSReq event > from the next 2 important points. right? Taisuke, Almost correct. > > R1) The premature aging process guarantees that > MaxAge LSA is never flushed from its link state database > as long as it is contained on any neighbor LS-Retransmission > list. > (this is what Acee pointed out) RFC 2328 states that a MaxAge LSA shouldn't be deleted from the link state database as long as there are neighbors in Exchange or Loading state. > > R2) Receiving R1's MaxAge LSA makes R2 delete the same instance of > the LSA from the LS-Request list associated with R1, if needed. > (this is what Sina pointed out) Yes. > > +---+ +---+ > |R1 |----------------|R2 | > +---+ +---+ > > > > >>Taisuke >> >>-> The point is below: >>-> 1) R1 told R2 that R1 had an Intra-Area-Prefix-LSA associated >>-> with a Router-LSA in Database Description packets. >>-> So, R2 will request the Intra-Area-Prefix-LSA. >>-> >>-> nevertheless, >>-> >>-> 2) When R1 receives a LS-Request packet from R2, >>-> it is possible that R2's neighbor state is already full, >> >>I guess you meant to say "R1's neighbor state is already Full" >> >>-> and there is no router in exchange or loading state, >>-> and an Intra-Area-Prefix-LSA associated with a Router-LSA >>-> is already flushed in R1's link state database. >>-> So, BadLSReq event will happen. >> >>The point that you missed is that when R1 maxage its LSA it is expecting >>to get an Ack and when R2 receive the Maxage LSA it will remove it from >>its link state request list ( a part from sending an Ack ) >> >>-- >> >>From 2328 >> >>(b) Else, if the adjacency is not yet full (neighbor state >> is Exchange or Loading), examine the Link state request >> list associated with this adjacency. If there is an >> instance of the new LSA on the list, it indicates that >> the neighboring router has an instance of the LSA >> already. Compare the new LSA to the neighbor's copy: >> >> o If the new LSA is less recent, then examine the next >> neighbor. >> >> o If the two copies are the same instance, then delete >> the LSA from the Link state request list, and >> examine the next neighbor.[20] >> >> o Else, the new LSA is more recent. Delete the LSA >> from the Link state request list. >>-- >> >> >>Sina > > > --- > taisuke sasaki > -- Acee From owner-ospf@PEACH.EASE.LSOFT.COM Wed May 28 10:10:29 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04484 for ; Wed, 28 May 2003 10:10:29 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.009E89C4@cherry.ease.lsoft.com>; Wed, 28 May 2003 10:10:28 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 43937168 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 28 May 2003 10:10:26 -0400 Received: from 204.192.44.242 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 28 May 2003 10:10:26 -0400 Received: (qmail 28293 invoked from network); 28 May 2003 14:10:27 -0000 Received: from unknown (HELO xebeo.com) (192.168.2.180) by lxmail.xebeo.com with SMTP; 28 May 2003 14:10:27 -0000 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <3ED4BAF6.3000804@redback.com> X-Enigmail-Version: 0.63.3.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3ED4C31B.3040007@xebeo.com> Date: Wed, 28 May 2003 16:09:31 +0200 Reply-To: Mailing List Sender: Mailing List From: Tony Przygienda Subject: Re: Vendor attributes in TE LSAs - (Sent first reply prematurely) To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Acee Lindem wrote: > Manral, Vishwas wrote: > >> Hi Acee, >> >> Though you can have vendor specific TLV encodings, the issue is there >> may be >> a clash in the TLV or Sub-TLV values. >> >> By using an SMI enterprise code or OUI to distinguish between various >> vendor >> specific implementations, we have one value that can be used by vendors >> instead of taking any TLV values, and we do not confuse information by >> various vendors, which are used for different purposes. > > > Hi Vishwas, > > I understood the motivation. I think the SMI enterprise code is a better > choice than the OUI since it is administered by IANA. However, I'm > against > the basic premise of allowing every vendor to roll their own TE LSAs and > carry them in OSPF. I believe doing so could impact 1) > Interoperability (there > isn't any) 2) Scalability (LSA contents, size, and refresh frequency are > unknown) and 3) Deployment - Debugging a multi-vendor network with many > different vendor specific LSAs will be difficult. ok, but then from experience, they will _just_ take the TLVs they need without letting you know. Suit yourself ;-) -- tony From owner-ospf@PEACH.EASE.LSOFT.COM Wed May 28 10:24:37 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05688 for ; Wed, 28 May 2003 10:24:37 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.009E8BE5@cherry.ease.lsoft.com>; Wed, 28 May 2003 10:24:37 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 43937635 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 28 May 2003 10:24:34 -0400 Received: from 209.202.99.50 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 28 May 2003 10:24:32 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Thread-Topic: Vendor attributes in TE LSAs Thread-Index: AcMkbn9w3zcLKF/RQ2Sbi3lS9X3RCwAtehZg Message-ID: <83040F98B407E6428FEC18AC720F5D73276CE9@exchange.tropicnetworks.com> Date: Wed, 28 May 2003 10:24:31 -0400 Reply-To: Mailing List Sender: Mailing List From: Udo Neustadter Subject: Re: Vendor attributes in TE LSAs To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA05688 Thank you Vishwas. I read the isis-experimental-tlv draft you mention and sections 5 and 6 in that draft seem applicable. A new version of my draft will include similar notes. Udo > -----Original Message----- > From: Manral, Vishwas [mailto:VishwasM@NETPLANE.COM] > Sent: Tuesday, May 27, 2003 12:41 > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Re: Vendor attributes in TE LSAs > > > Hi Udo, > > The draft looks pretty straight forward and simple. > > A similar draft exists in IS-IS > http://www.ietf.org/internet-drafts/draft-ietf-isis-experiment al-tlv-00.txt , and instead of "SMI Network management enterprise code for the vendor or organization" uses "a valid IEEE assigned OUI as the first three bytes of the value of the TLV." I do not know the tradeoffs but if possible we could use the same value too. Maybe someone could point out the tradeoffs if any. Besides I guess Section 5(if the same mechanism is used in TLV's) and Section 6 of the ISIS draft wold be valid here too. Thanks, Vishwas -----Original Message----- From: Udo Neustadter [mailto:neustadter@TROPICNETWORKS.COM] Sent: Tuesday, May 27, 2003 6:49 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Vendor attributes in TE LSAs Hi all, I am working on a GMPLS implementation, and part of my problem is the addition of company specific data to the TE LSAs. The Internet-Draft http://www.ietf.org/internet-drafts/draft-udo-ospf-vendatt-00.txt proposes an interoperable way to solve the following two issues: 1. Companies that already applied with IANA for an SMI Network management enterprise code do not need to re-apply for sub-TLV values from the pool of numbers reserved for private use 2. Allows private attributes/data to be embedded in the TE router LSA (the one TE LSA that contains the router address TLV). I would like for the draft to be considered part of this working group. This work is an extension to the work done in http://www.ietf.org/internet-drafts/draft-katz-yeung-ospf-traffic-09.txt and http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-gmpls-extensio ns-09.txt. Thanks in advance for your support. Udo From owner-ospf@PEACH.EASE.LSOFT.COM Wed May 28 10:24:43 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05704 for ; Wed, 28 May 2003 10:24:42 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.009E8BE6@cherry.ease.lsoft.com>; Wed, 28 May 2003 10:24:42 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 43937648 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 28 May 2003 10:24:39 -0400 Received: from 24.93.67.84 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 28 May 2003 10:24:39 -0400 Received: from redback.com (rdu26-55-006.nc.rr.com [66.26.55.6]) by ms-smtp-03.southeast.rr.com (8.12.5/8.12.2) with ESMTP id h4SEN7Zo025666 for ; Wed, 28 May 2003 10:23:07 -0400 (EDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <3ED4BAF6.3000804@redback.com> <3ED4C31B.3040007@xebeo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3ED4C640.5010704@redback.com> Date: Wed, 28 May 2003 10:22:56 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Vendor attributes in TE LSAs - (Sent first reply prematurely) To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Tony Przygienda wrote: > Acee Lindem wrote: > > >>Manral, Vishwas wrote: >> >> >>>Hi Acee, >>> >>>Though you can have vendor specific TLV encodings, the issue is there >>>may be >>>a clash in the TLV or Sub-TLV values. >>> >>>By using an SMI enterprise code or OUI to distinguish between various >>>vendor >>>specific implementations, we have one value that can be used by vendors >>>instead of taking any TLV values, and we do not confuse information by >>>various vendors, which are used for different purposes. >> >> >>Hi Vishwas, >> >>I understood the motivation. I think the SMI enterprise code is a better >>choice than the OUI since it is administered by IANA. However, I'm >>against >>the basic premise of allowing every vendor to roll their own TE LSAs and >>carry them in OSPF. I believe doing so could impact 1) >>Interoperability (there >>isn't any) 2) Scalability (LSA contents, size, and refresh frequency are >>unknown) and 3) Deployment - Debugging a multi-vendor network with many >>different vendor specific LSAs will be difficult. > > > ok, but then from experience, they will _just_ take the TLVs they need > without > letting you know. Suit yourself ;-) Maybe so - but at least this activity won't be sanctioned by the OSPF WG. Perhaps the IANA allocation of TLVs and Sub-TLVs needs to be at the front end of the process rather than the backend. > > -- tony > -- Acee From owner-ospf@PEACH.EASE.LSOFT.COM Wed May 28 10:27:20 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05758 for ; Wed, 28 May 2003 10:27:20 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.009E8B65@cherry.ease.lsoft.com>; Wed, 28 May 2003 10:27:19 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 43937705 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 28 May 2003 10:27:16 -0400 Received: from 209.202.99.50 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 28 May 2003 10:27:16 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Thread-Topic: Vendor attributes in TE LSAs Thread-Index: AcMk0xNd1roNADj8RqijtZNnSCcWzwATc9ag Message-ID: <83040F98B407E6428FEC18AC720F5D73200F0C@exchange.tropicnetworks.com> Date: Wed, 28 May 2003 10:27:16 -0400 Reply-To: Mailing List Sender: Mailing List From: Udo Neustadter Subject: Re: Vendor attributes in TE LSAs To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA05758 Hello Acee, The method described in katz-yeung-ospf-traffic is quite clear that the assignment for sub Types in the TE Link TLV in the range from 32773 through 65535 does not involve the OSPF WG, TE WG, nor the IETF. It is merely a formality with IANA to get such a number on a first come first serve basis. This number, however easy to get, is something that must be managed "forever" by IANA and the vendors. My draft makes it easier for both IANA and the Vendors. The draft also specifies the addition of data to the Router Address TLV, which is completely missing under today's set of documents. I feel very strongly that it is important to allow for extensions in the TE router LSA. On another note, I think the real question that needs to be answered here is the kind of data that goes into the VendAtt sub-TLV. I our case for instance that is data we are not ready to make public and/or have a roadmap that shows the evolution of the protocol for some years to come. I don't think the community would support such an evolving standard. Just the fact that katz-yeung-ospf-traffic reserves a range of sub-TLVs for private use proves that there is a need to have private data in the TE LSA. Regards, Udo > -----Original Message----- > From: Acee Lindem [mailto:acee@REDBACK.COM] > Sent: Wednesday, May 28, 2003 00:37 > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Re: Vendor attributes in TE LSAs - (Sent first reply > prematurely) > > > References: > <83040F98B407E6428FEC18AC720F5D73200F09@exchange.tropicnetwork > s.com> <3ED438B5.1070000@redback.com> > Content-Type: text/plain; charset=us-ascii; format=flowed > Content-Transfer-Encoding: 7bit > > Udo, > > Aside from any technical details, I don't agree with this > draft philosophically. In essence, it is a proposal to > standardise on a mechanism to be non-standard. More > specifically, it removes the OSPF WG, TE WG, and IETF in > general from reviewing the vendor specific TLVs. The > contents, size, and refresh rate of these TLVs are unknown. > > By definition, there is no interoperability. The same set of > problems will undoubtedly be solved in multiple ways by > different vendors using different vendor specific TLV encodings. > > Acee Lindem wrote: > > Udo, > > > > I don't support this enhancement since it essentially removes any > > > > > > Udo Neustadter wrote: > > > >> Hi all, > >> > >> I am working on a GMPLS implementation, and part of my > problem is the > >> addition of company specific data to the TE LSAs. The > Internet-Draft > >> http://www.ietf.org/internet-drafts/draft-udo-ospf-vendatt-00.txt > >> proposes an interoperable way to solve the following two issues: > >> 1. Companies that already applied with IANA for an SMI Network > >> management enterprise code do not need to re-apply for > sub-TLV values > >> from the pool of numbers reserved for private use > >> 2. Allows private attributes/data to be embedded in the > TE router > >> LSA (the one TE LSA that contains the router address TLV). > >> > >> I would like for the draft to be considered part of this working > >> group. This work is an extension to the work done in > >> > http://www.ietf.org/internet-drafts/draft-> katz-yeung-ospf-traffic-09. > >> txt > >> and > >> > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-gmpl s-extensio >> ns-09.txt. >> >> Thanks in advance for your support. >> >> Udo >> > > > -- > Acee > -- Acee From owner-ospf@PEACH.EASE.LSOFT.COM Wed May 28 11:23:30 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08164 for ; Wed, 28 May 2003 11:23:30 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.009E8D76@cherry.ease.lsoft.com>; Wed, 28 May 2003 11:23:30 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 43940121 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 28 May 2003 11:23:27 -0400 Received: from 199.46.198.233 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 28 May 2003 11:13:26 -0400 Received: from ds02e00.directory.ray.com (ds02e00.directory.ray.com [147.25.130.245]) by bos-gate4.raytheon.com (8.12.9/8.12.9) with ESMTP id h4SFDRsi019711 for ; Wed, 28 May 2003 11:13:27 -0400 (EDT) Received: from ds02e00.directory.ray.com (localhost [127.0.0.1]) by ds02e00.directory.ray.com (8.12.9/8.12.1) with ESMTP id h4SFDPfK012862 for ; Wed, 28 May 2003 15:13:25 GMT Received: Received: from ad2-mta02.and.us.ray.com (ad2-mta02.and.us.ray.com [138.127.59.160]) by ds02e00.directory.ray.com (8.12.9/8.12.9) with ESMTP id h4SFDIb0012771 sender Navid_Yazdani@raytheon.com for ; Wed, 28 May 2003 15:13:21 GMT X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Message-ID: Date: Wed, 28 May 2003 11:13:09 -0400 Reply-To: Mailing List Sender: Mailing List From: Navid Yazdani Subject: rfc2676 To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Is there a commercial implementation of RFC2676 "QoS Routing Mechanisms and OSPF Extensions" ? Are there any other standards that specify how routing protocols will carry QoS information -- specifically how much bandwidth is currently used on a link? Is there any commercial equipment that supports dynamic link information for routing? thanks Navid Yazdani navid_yazdani@raytheon.com From owner-ospf@PEACH.EASE.LSOFT.COM Wed May 28 12:38:03 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11319 for ; Wed, 28 May 2003 12:38:03 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.009E9554@cherry.ease.lsoft.com>; Wed, 28 May 2003 12:37:59 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 43944403 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 28 May 2003 12:15:36 -0400 Received: from 204.192.44.242 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 28 May 2003 12:15:34 -0400 Received: (qmail 4367 invoked from network); 28 May 2003 16:15:34 -0000 Received: from unknown (HELO xebeo.com) (192.168.2.180) by lxmail.xebeo.com with SMTP; 28 May 2003 16:15:34 -0000 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <3ED4BAF6.3000804@redback.com> <3ED4C31B.3040007@xebeo.com> <3ED4C640.5010704@redback.com> X-Enigmail-Version: 0.63.3.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3ED4E06B.9060008@xebeo.com> Date: Wed, 28 May 2003 18:14:35 +0200 Reply-To: Mailing List Sender: Mailing List From: Tony Przygienda Subject: Re: Vendor attributes in TE LSAs - (Sent first reply prematurely) To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Acee Lindem wrote: > Tony Przygienda wrote: > >> Acee Lindem wrote: >> >> >>>> >>> >>> isn't any) 2) Scalability (LSA contents, size, and refresh frequency >>> are >>> unknown) and 3) Deployment - Debugging a multi-vendor network with many >>> different vendor specific LSAs will be difficult. >> >> >> >> ok, but then from experience, they will _just_ take the TLVs they need >> without >> letting you know. Suit yourself ;-) > > > Maybe so - but at least this activity won't be sanctioned by the OSPF WG. this is just a semantic or maybe semiotic split-of-hairs IMHO. OSPF-WG or any other WG-approval is not a consumer brand and does nothing for the vendor, espeically if he's pursuiting a proprietary value-add-on in the protocol. > > > Perhaps the IANA allocation of TLVs and Sub-TLVs needs to be at the front > end of the process rather than the backend. yes, but is easier for vendors to grab an 'experimental' OUI (which is a no-time-involved process) and once they figured out what it does for them and care about interoperability, ask for an 'official' sub-TLV. It will be a well-understood process by both vendors AND their customers. Customers will understand that an 'experimental' gives them no guarantee as to itneroperability as Ran very clearly formulated and has been put down in the isis-experimental draft. Otherwise they'll ask you for a sub-TLV or probaly not even that (since it needs time, so they just grab any number that looks free) and of course not tell you what it does. Difference against just semantical IMHO and in terms of reality the output is the same thanks -- tony From owner-ospf@PEACH.EASE.LSOFT.COM Wed May 28 13:43:16 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13136 for ; Wed, 28 May 2003 13:43:16 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.009E9F54@cherry.ease.lsoft.com>; Wed, 28 May 2003 13:43:13 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 43951102 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 28 May 2003 13:40:42 -0400 Received: from 207.217.120.120 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 28 May 2003 13:40:42 -0400 Received: from user-38ldtro.dialup.mindspring.com ([209.86.247.120] helo=earthlink.net) by albatross.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 19L4um-0004ul-00; Wed, 28 May 2003 10:40:41 -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: <200305272156.RAA04068@ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3ED4F4A3.E6399115@earthlink.net> Date: Wed, 28 May 2003 10:40:51 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: Last Call: Detecting Inactive Neighbors over OSPF Demand Circuits to Proposed Standard Comments: To: iesg@ietf.org To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit This document has a exiration date of Sep. 03. Is it proper to consider this draft 3 months before that expiration date. Mitchell Erblich ---------------------------- The IESG wrote: > > The IESG has received a request from the Open Shortest Path > First IGP Working Group to consider Detecting Inactive Neighbors > over OSPF Demand Circuits as a > Proposed Standard. > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send any comments to the > iesg@ietf.org or ietf@ietf.org mailing lists by 2003-6-10. > > Files can be obtained > via http://www.ietf.org/internet-drafts/draft-ietf-ospf-dc-06.txt From owner-ospf@PEACH.EASE.LSOFT.COM Wed May 28 14:08:45 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14248 for ; Wed, 28 May 2003 14:08:45 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.009E9FF9@cherry.ease.lsoft.com>; Wed, 28 May 2003 14:08:44 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 43955123 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 28 May 2003 14:08:42 -0400 Received: from 24.93.67.82 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 28 May 2003 14:08:32 -0400 Received: from redback.com (rdu26-55-006.nc.rr.com [66.26.55.6]) by ms-smtp-01.southeast.rr.com (8.12.5/8.12.2) with ESMTP id h4SI3Esb012021 for ; Wed, 28 May 2003 14:03:14 -0400 (EDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <3ED4BAF6.3000804@redback.com> <3ED4C31B.3040007@xebeo.com> <3ED4C640.5010704@redback.com> <3ED4E06B.9060008@xebeo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3ED4FAB6.3080600@redback.com> Date: Wed, 28 May 2003 14:06:46 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Vendor attributes in TE LSAs - (Sent first reply prematurely) To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Tony Przygienda wrote: > Acee Lindem wrote: > > >>Tony Przygienda wrote: >> >> >>>Acee Lindem wrote: >>> >>> >>> >>>>isn't any) 2) Scalability (LSA contents, size, and refresh frequency >>>>are >>>>unknown) and 3) Deployment - Debugging a multi-vendor network with many >>>>different vendor specific LSAs will be difficult. >>> >>> >>> >>>ok, but then from experience, they will _just_ take the TLVs they need >>>without >>>letting you know. Suit yourself ;-) >> >> >>Maybe so - but at least this activity won't be sanctioned by the OSPF WG. > > > this is just a semantic or maybe semiotic split-of-hairs IMHO. OSPF-WG > or any > other WG-approval is not a consumer brand and does nothing for the vendor, > espeically if he's pursuiting a proprietary value-add-on in the protocol. > > >> >>Perhaps the IANA allocation of TLVs and Sub-TLVs needs to be at the front >>end of the process rather than the backend. > > > yes, but is easier for vendors to grab an 'experimental' OUI (which is a > no-time-involved > process) and once they figured > out what it does for them and care about interoperability, ask for an > 'official' sub-TLV. > It will be a well-understood process by both vendors AND their > customers. Customers > will understand that an 'experimental' gives them no guarantee as to > itneroperability as > Ran very clearly formulated and has been put down in the > isis-experimental draft. > Otherwise they'll ask you for a sub-TLV or probaly not even that (since > it needs time, so > they > just grab any number that looks free) > and of course not tell you what it does. Difference against just > semantical IMHO > and in terms of > reality the output is the same I'd be prefer an experimental range of TLVs that are allocated from IANA for specific experimental purposes rather than a single TLV giving carte blanche to advertise anything in OSPF. I'm less cynical that the output will be the same. Hopefully, if an experimental TE application is commerically viable it will evolve into a standard. > > thanks > > -- tony > -- Acee From owner-ospf@PEACH.EASE.LSOFT.COM Wed May 28 14:20:02 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14606 for ; Wed, 28 May 2003 14:20:02 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.009EA033@cherry.ease.lsoft.com>; Wed, 28 May 2003 14:20:01 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 43955723 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 28 May 2003 14:20:00 -0400 Received: from 24.93.67.82 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 28 May 2003 14:20:00 -0400 Received: from redback.com (rdu26-55-006.nc.rr.com [66.26.55.6]) by ms-smtp-01.southeast.rr.com (8.12.5/8.12.2) with ESMTP id h4SIEgsb019360 for ; Wed, 28 May 2003 14:14:42 -0400 (EDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <200305272156.RAA04068@ietf.org> <3ED4F4A3.E6399115@earthlink.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3ED4FD65.7050506@redback.com> Date: Wed, 28 May 2003 14:18:13 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Last Call: Detecting Inactive Neighbors over OSPF Demand Circuits to Proposed Standard To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Erblichs wrote: > This document has a exiration date of Sep. 03. > > Is it proper to consider this draft 3 months > before that expiration date. Mitchell, The IETF wide last call ends on 2003-6-10 - this is well before the draft expires. Thanks, Acee > > Mitchell Erblich > ---------------------------- > > The IESG wrote: > >>The IESG has received a request from the Open Shortest Path >>First IGP Working Group to consider Detecting Inactive Neighbors >>over OSPF Demand Circuits as a >>Proposed Standard. >> >>The IESG plans to make a decision in the next few weeks, and solicits >>final comments on this action. Please send any comments to the >>iesg@ietf.org or ietf@ietf.org mailing lists by 2003-6-10. >> >>Files can be obtained >>via http://www.ietf.org/internet-drafts/draft-ietf-ospf-dc-06.txt > > -- Acee From owner-ospf@PEACH.EASE.LSOFT.COM Wed May 28 15:11:20 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17979 for ; Wed, 28 May 2003 15:11:19 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.009EA04A@cherry.ease.lsoft.com>; Wed, 28 May 2003 15:11:18 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 43962121 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 28 May 2003 15:11:16 -0400 Received: from 207.217.120.48 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 28 May 2003 15:11:16 -0400 Received: from user-38ldtro.dialup.mindspring.com ([209.86.247.120] helo=earthlink.net) by mallard.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 19L6KQ-0005p2-00 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 28 May 2003 12:11:15 -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: <3ED509DA.C7720CAB@earthlink.net> Date: Wed, 28 May 2003 12:11:22 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: FW: Last Call: Detecting Inactive Neighbors over OSPF Demand To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit "L-Soft list server at PEACH.EASE.LSOFT.COM (1.8e)" wrote: > > Your message is being returned to you unprocessed because it looks like a > LISTSERV command, rather than material intended for distribution to the members > of the OSPF list. Please note that LISTSERV commands must ALWAYS be sent to the > LISTSERV address; if it was indeed a command you were attempting to issue, > please send it again to LISTSERV@PEACH.EASE.LSOFT.COM for execution. Otherwise, > please accept our apologies and try to rewrite the message with a slightly > different wording - for instance, change the first word of the message, enclose > it in quotation marks, insert a line of dashes at the beginning of your > message, etc. > > ------------------------------------------------------------------------ > > Subject: Re: FW: Last Call: Detecting Inactive Neighbors over OSPF Demand > Circuits to Proposed Standard > Date: Wed, 28 May 2003 11:52:47 -0700 > From: Erblichs > To: OSPF@PEACH.EASE.LSOFT.COM, iesg@ietf.org > References: > > Ok, > > If I wanted to look into the draft itself, then I have 4 suggestions > labed A, B, C, and D. > > A) No order is implied.. > 2. "When application traffic starts going over the link, the > link is brought up, and the routers may probe each other." > > The wording could be improved to specify: > > After the link is brought up, a probe SHOULD be sent if ..ProbeInterval > has expired, and after verifying a successful probe, then application > data can be sent. > > B) Configurable Parameters > > Did I see any usage of these parameters in the draft? Shouldn't > some wording be used for them in the draft before the > appendix? > > C) ...ProbeInterval > > I question whether a sucessful probe that is specified in this > draft will guarantee that even with link that is up that application > traffic will be properly recieved. > > Why? A probe with a minimum packet/frame size may succeed in > a buffer allocation where application traffic may use a MTU > size packet. Thus, probes should be of MTU size. > (this type of verification is done in IS-IS) > > Thus, I would add a suggested probe size of MTU size. > > D) .. ProbeInterval > > I question that an demand link uptime can be shorter > than ..ProbeInterval. In the event that ..ProbeInterval > is longer than successive application transmissions, then > some application traffic is sent without a prior probe. > > Thus, for the paranoid of us, I would expect that a probe be sent > before and after application data. This would allow a higher > assurance level of successful transmission of the application > data. > > Thus, my suggestion is to remove the ..ProbeInterval config > value and suggest bracketing application data with probes. > > My only issue, is if the first probe succeeded and the 2nd failed, > then what do you do? > > Minimally, I would expect a probe before each application transmit > and remove the ..ProbeInterval config value. > > Mitchell Erblich > Sr Software Engineer > ----------------------- > > > > > > > The IESG wrote: > > > > > > > > The IESG has received a request from the Open Shortest Path > > > > First IGP Working Group to consider Detecting Inactive Neighbors > > > > over OSPF Demand Circuits as a > > > > Proposed Standard. > > > > > > > > The IESG plans to make a decision in the next few weeks, > > > and solicits > > > > final comments on this action. Please send any comments to the > > > > iesg@ietf.org or ietf@ietf.org mailing lists by 2003-6-10. > > > > > > > > Files can be obtained > > > > via http://www.ietf.org/internet-drafts/draft-ietf-ospf-dc-06.txt > > > From owner-ospf@PEACH.EASE.LSOFT.COM Wed May 28 16:23:44 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22050 for ; Wed, 28 May 2003 16:23:44 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.009EA23F@cherry.ease.lsoft.com>; Wed, 28 May 2003 16:23:43 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 43967974 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 28 May 2003 16:23:41 -0400 Received: from 171.71.177.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 28 May 2003 16:23:41 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h4SKNd9x002808 for ; Wed, 28 May 2003 13:23:40 -0700 (PDT) Received: from irp-view7.cisco.com (irp-view7.cisco.com [171.70.65.144]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AHN88206; Wed, 28 May 2003 13:20:44 -0700 (PDT) References: <3ED509DA.C7720CAB@earthlink.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Wed, 28 May 2003 13:23:34 -0700 Reply-To: Mailing List Sender: Mailing List From: Abhay Roy Subject: Re: FW: Last Call: Detecting Inactive Neighbors over OSPF Demand To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <3ED509DA.C7720CAB@earthlink.net> Precedence: list Mitchell, Please see some comments inline.. > > Date: Wed, 28 May 2003 11:52:47 -0700 > > From: Erblichs > > To: OSPF@PEACH.EASE.LSOFT.COM, iesg@ietf.org > > References: > > > > Ok, > > > > If I wanted to look into the draft itself, then I have 4 suggestions > > labed A, B, C, and D. > > > > A) No order is implied.. > > 2. "When application traffic starts going over the link, the > > link is brought up, and the routers may probe each other." > > > > The wording could be improved to specify: > > > > After the link is brought up, a probe SHOULD be sent if ..ProbeInterval > > has expired, and after verifying a successful probe, then application > > data can be sent. We can change MAY to a SHOULD. The latter part implies that the data should not be sent till the probe succeeds.. I don't think there is any need to be that extreme. The success of probes depends on possibly retransmitting the Update packet multiple times. And I don't see much value (except maybe in the case, when the neighbor is indeed dead) in dropping the data for that much time. > > B) Configurable Parameters > > > > Did I see any usage of these parameters in the draft? Shouldn't > > some wording be used for them in the draft before the > > appendix? We got the same comment from the AD ;) We will fix it.. > > C) ...ProbeInterval > > > > I question whether a sucessful probe that is specified in this > > draft will guarantee that even with link that is up that application > > traffic will be properly recieved. > > > > Why? A probe with a minimum packet/frame size may succeed in > > a buffer allocation where application traffic may use a MTU > > size packet. Thus, probes should be of MTU size. > > (this type of verification is done in IS-IS) > > > > Thus, I would add a suggested probe size of MTU size. OSPF uses Interface MTU during DBD exchange to make sure that MTU's match.. If there was an MTU problem, the adjacency will not progress to FULL state.. The probe is just an OSPF update packet, so it has no size restrictions.. > > D) .. ProbeInterval > > > > I question that an demand link uptime can be shorter > > than ..ProbeInterval. In the event that ..ProbeInterval > > is longer than successive application transmissions, then > > some application traffic is sent without a prior probe. > > > > Thus, for the paranoid of us, I would expect that a probe be sent > > before and after application data. This would allow a higher > > assurance level of successful transmission of the application > > data. > > > > Thus, my suggestion is to remove the ..ProbeInterval config > > value and suggest bracketing application data with probes. > > > > My only issue, is if the first probe succeeded and the 2nd failed, > > then what do you do? > > > > Minimally, I would expect a probe before each application transmit > > and remove the ..ProbeInterval config value. To me, the probe is just a background task to verify the viability of the DC link to a neighbor. I don't see how data plane waiting for control plane verification is going to help.. Regards, -Roy- > > Mitchell Erblich > > Sr Software Engineer > > ----------------------- > > > > > > > > > > The IESG wrote: > > > > > > > > > > The IESG has received a request from the Open Shortest Path > > > > > First IGP Working Group to consider Detecting Inactive Neighbors > > > > > over OSPF Demand Circuits as a > > > > > Proposed Standard. > > > > > > > > > > The IESG plans to make a decision in the next few weeks, > > > > and solicits > > > > > final comments on this action. Please send any comments to the > > > > > iesg@ietf.org or ietf@ietf.org mailing lists by 2003-6-10. > > > > > > > > > > Files can be obtained > > > > > via http://www.ietf.org/internet-drafts/draft-ietf-ospf-dc-06.txt > > > > > > From owner-ospf@PEACH.EASE.LSOFT.COM Wed May 28 17:28:31 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25094 for ; Wed, 28 May 2003 17:28:31 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.009EA549@cherry.ease.lsoft.com>; Wed, 28 May 2003 17:28:27 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 43971957 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 28 May 2003 17:28:22 -0400 Received: from 24.93.67.84 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 28 May 2003 17:28:22 -0400 Received: from redback.com (rdu163-33-145.nc.rr.com [24.163.33.145]) by ms-smtp-03.southeast.rr.com (8.12.5/8.12.2) with ESMTP id h4SLQlZo007348 for ; Wed, 28 May 2003 17:26:48 -0400 (EDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <3ED509DA.C7720CAB@earthlink.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3ED5298A.4040503@redback.com> Date: Wed, 28 May 2003 17:26:34 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: FW: Last Call: Detecting Inactive Neighbors over OSPF Demand To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit I agree with Abhay on all points. Especially that we do not want to make this a mechanism to verify MTU agreement or verify the data plane. It is solely a mechanism to detech dead OSPF neighbors over demand circuits. Abhay Roy wrote: > Mitchell, > > Please see some comments inline.. > > >>>Date: Wed, 28 May 2003 11:52:47 -0700 >>>From: Erblichs >>>To: OSPF@PEACH.EASE.LSOFT.COM, iesg@ietf.org >>>References: >>> >>>Ok, >>> >>> If I wanted to look into the draft itself, then I have 4 suggestions >>> labed A, B, C, and D. >>> >>> A) No order is implied.. >>> 2. "When application traffic starts going over the link, the >>> link is brought up, and the routers may probe each other." >>> >>> The wording could be improved to specify: >>> >>> After the link is brought up, a probe SHOULD be sent if ..ProbeInterval >>> has expired, and after verifying a successful probe, then application >>> data can be sent. >> > > We can change MAY to a SHOULD. > > The latter part implies that the data should not be sent till the > probe succeeds.. I don't think there is any need to be that > extreme. The success of probes depends on possibly retransmitting > the Update packet multiple times. And I don't see much value > (except maybe in the case, when the neighbor is indeed dead) in > dropping the data for that much time. > > >>> B) Configurable Parameters >>> >>> Did I see any usage of these parameters in the draft? Shouldn't >>> some wording be used for them in the draft before the >>> appendix? >> > > We got the same comment from the AD ;) We will fix it.. > > >>> C) ...ProbeInterval >>> >>> I question whether a sucessful probe that is specified in this >>> draft will guarantee that even with link that is up that application >>> traffic will be properly recieved. >>> >>> Why? A probe with a minimum packet/frame size may succeed in >>> a buffer allocation where application traffic may use a MTU >>> size packet. Thus, probes should be of MTU size. >>> (this type of verification is done in IS-IS) >>> >>> Thus, I would add a suggested probe size of MTU size. >> > > OSPF uses Interface MTU during DBD exchange to make sure that > MTU's match.. If there was an MTU problem, the adjacency will not > progress to FULL state.. The probe is just an OSPF update packet, > so it has no size restrictions.. > > >>> D) .. ProbeInterval >>> >>> I question that an demand link uptime can be shorter >>> than ..ProbeInterval. In the event that ..ProbeInterval >>> is longer than successive application transmissions, then >>> some application traffic is sent without a prior probe. >>> >>> Thus, for the paranoid of us, I would expect that a probe be sent >>> before and after application data. This would allow a higher >>> assurance level of successful transmission of the application >>> data. >>> >>> Thus, my suggestion is to remove the ..ProbeInterval config >>> value and suggest bracketing application data with probes. >>> >>> My only issue, is if the first probe succeeded and the 2nd failed, >>> then what do you do? >>> >>> Minimally, I would expect a probe before each application transmit >>> and remove the ..ProbeInterval config value. >> > > To me, the probe is just a background task to verify the viability > of the DC link to a neighbor. I don't see how data plane waiting > for control plane verification is going to help.. > > Regards, > -Roy- > > > >>> Mitchell Erblich >>> Sr Software Engineer >>> ----------------------- >>> >>> >>>>>The IESG wrote: >>>>> >>>>>>The IESG has received a request from the Open Shortest Path >>>>>>First IGP Working Group to consider Detecting Inactive Neighbors >>>>>>over OSPF Demand Circuits as a >>>>>>Proposed Standard. >>>>>> >>>>>>The IESG plans to make a decision in the next few weeks, >>>>> >>>>>and solicits >>>>> >>>>>>final comments on this action. Please send any comments to the >>>>>>iesg@ietf.org or ietf@ietf.org mailing lists by 2003-6-10. >>>>>> >>>>>>Files can be obtained >>>>>>via http://www.ietf.org/internet-drafts/draft-ietf-ospf-dc-06.txt >>>>> >> > -- Acee From owner-ospf@PEACH.EASE.LSOFT.COM Wed May 28 18:26:12 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27950 for ; Wed, 28 May 2003 18:26:11 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.009EA546@cherry.ease.lsoft.com>; Wed, 28 May 2003 18:26:11 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 43975002 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 28 May 2003 18:26:09 -0400 Received: from 207.217.120.18 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 28 May 2003 18:26:09 -0400 Received: from user-38ldtro.dialup.mindspring.com ([209.86.247.120] helo=earthlink.net) by goose.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 19L7CJ-0006bY-00 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 28 May 2003 13:06:56 -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: <3ED509DA.C7720CAB@earthlink.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3ED516E3.35CF71BB@earthlink.net> Date: Wed, 28 May 2003 13:06:59 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: FW: Last Call: Detecting Inactive Neighbors over OSPF Demand To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Sorry group, I forgot.. E) If ..ProbeInterval is kept, its max value MUST not exceed 1 hr.. I think this follows that if we haven't heard from our nbr in 1 hr "he" is considered dead. Mitchell Erblich ------------------- Erblichs wrote: > > "L-Soft list server at PEACH.EASE.LSOFT.COM (1.8e)" wrote: > > > > Your message is being returned to you unprocessed because it looks like a > > LISTSERV command, rather than material intended for distribution to the members > > of the OSPF list. Please note that LISTSERV commands must ALWAYS be sent to the > > LISTSERV address; if it was indeed a command you were attempting to issue, > > please send it again to LISTSERV@PEACH.EASE.LSOFT.COM for execution. Otherwise, > > please accept our apologies and try to rewrite the message with a slightly > > different wording - for instance, change the first word of the message, enclose > > it in quotation marks, insert a line of dashes at the beginning of your > > message, etc. > > > > ------------------------------------------------------------------------ > > > > Subject: Re: FW: Last Call: Detecting Inactive Neighbors over OSPF Demand > > Circuits to Proposed Standard > > Date: Wed, 28 May 2003 11:52:47 -0700 > > From: Erblichs > > To: OSPF@PEACH.EASE.LSOFT.COM, iesg@ietf.org > > References: > > > > Ok, > > > > If I wanted to look into the draft itself, then I have 4 suggestions > > labed A, B, C, and D. > > > > A) No order is implied.. > > 2. "When application traffic starts going over the link, the > > link is brought up, and the routers may probe each other." > > > > The wording could be improved to specify: > > > > After the link is brought up, a probe SHOULD be sent if ..ProbeInterval > > has expired, and after verifying a successful probe, then application > > data can be sent. > > > > B) Configurable Parameters > > > > Did I see any usage of these parameters in the draft? Shouldn't > > some wording be used for them in the draft before the > > appendix? > > > > C) ...ProbeInterval > > > > I question whether a sucessful probe that is specified in this > > draft will guarantee that even with link that is up that application > > traffic will be properly recieved. > > > > Why? A probe with a minimum packet/frame size may succeed in > > a buffer allocation where application traffic may use a MTU > > size packet. Thus, probes should be of MTU size. > > (this type of verification is done in IS-IS) > > > > Thus, I would add a suggested probe size of MTU size. > > > > D) .. ProbeInterval > > > > I question that an demand link uptime can be shorter > > than ..ProbeInterval. In the event that ..ProbeInterval > > is longer than successive application transmissions, then > > some application traffic is sent without a prior probe. > > > > Thus, for the paranoid of us, I would expect that a probe be sent > > before and after application data. This would allow a higher > > assurance level of successful transmission of the application > > data. > > > > Thus, my suggestion is to remove the ..ProbeInterval config > > value and suggest bracketing application data with probes. > > > > My only issue, is if the first probe succeeded and the 2nd failed, > > then what do you do? > > > > Minimally, I would expect a probe before each application transmit > > and remove the ..ProbeInterval config value. > > > > Mitchell Erblich > > Sr Software Engineer > > ----------------------- > > > > > > > > > > The IESG wrote: > > > > > > > > > > The IESG has received a request from the Open Shortest Path > > > > > First IGP Working Group to consider Detecting Inactive Neighbors > > > > > over OSPF Demand Circuits as a > > > > > Proposed Standard. > > > > > > > > > > The IESG plans to make a decision in the next few weeks, > > > > and solicits > > > > > final comments on this action. Please send any comments to the > > > > > iesg@ietf.org or ietf@ietf.org mailing lists by 2003-6-10. > > > > > > > > > > Files can be obtained > > > > > via http://www.ietf.org/internet-drafts/draft-ietf-ospf-dc-06.txt > > > > From owner-ospf@PEACH.EASE.LSOFT.COM Wed May 28 18:53:27 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28518 for ; Wed, 28 May 2003 18:53:26 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.009EA734@cherry.ease.lsoft.com>; Wed, 28 May 2003 18:53:27 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 43977035 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 28 May 2003 18:53:25 -0400 Received: from 171.71.177.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 28 May 2003 18:53:25 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h4SMrN9x014258 for ; Wed, 28 May 2003 15:53:23 -0700 (PDT) Received: from irp-view7.cisco.com (irp-view7.cisco.com [171.70.65.144]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AHO06583; Wed, 28 May 2003 15:50:31 -0700 (PDT) References: <3ED509DA.C7720CAB@earthlink.net> <3ED516E3.35CF71BB@earthlink.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Wed, 28 May 2003 15:53:22 -0700 Reply-To: Mailing List Sender: Mailing List From: Abhay Roy Subject: Re: FW: Last Call: Detecting Inactive Neighbors over OSPF Demand To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <3ED516E3.35CF71BB@earthlink.net> Precedence: list Mitchell, Why it MUST not exceed 1hr? Today it's infinity, so in theory any interval (including absurdly high ones) should be allowed. Regards, -Roy- On 05/28/03-0700 at 1:06pm, Erblichs writes: > Sorry group, > > I forgot.. > > E) If ..ProbeInterval is kept, its max value MUST not exceed > 1 hr.. > > I think this follows that if we haven't heard from our > nbr in 1 hr "he" is considered dead. > > Mitchell Erblich > ------------------- From owner-ospf@PEACH.EASE.LSOFT.COM Wed May 28 20:02:06 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00476 for ; Wed, 28 May 2003 20:02:05 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.009EA82C@cherry.ease.lsoft.com>; Wed, 28 May 2003 20:02:02 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 43981059 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 28 May 2003 20:02:00 -0400 Received: from 207.217.120.54 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 28 May 2003 20:02:00 -0400 Received: from user-38ldu7u.dialup.mindspring.com ([209.86.248.254] helo=earthlink.net) by conure.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 19LArm-0001WW-00 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 28 May 2003 17:01:58 -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: <3ED509DA.C7720CAB@earthlink.net> <3ED5298A.4040503@redback.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3ED54DE5.CE544E68@earthlink.net> Date: Wed, 28 May 2003 17:01:41 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: FW: Last Call: Detecting Inactive Neighbors over OSPF Demand To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Abhay Roy and Acee Lindem, If the mechanism is to detect only dead neighbors, then why wouldn't their be just a periodic probing of the neighbor every 45 minutes or so, without respect to the application data traffic? In addition, if a probe is recieved and responded to within the 1 hr time frame, then a probe in the reverse direction would not be necessary until the next time interval. If on the other hand it is important to know that the data was successfully transmitted over the DC (which infers a live nbr), then a verification of a successful probe, in my opinion should proceed the transmit of the application data. Lastly, my MTU size packet is not to verify that the link-MTUs match between the two nbrs. It is to verify that MTU size buffers are available for the incoming application traffic. It is assumed that a MTU probe length, will be of an insignificant amount of additional data and processing overhead. Mitchell Erblich Sr Software Engineer ------------------- Acee Lindem wrote: > > I agree with Abhay on all points. Especially that we do not want > to make this a mechanism to verify MTU agreement or verify the > data plane. It is solely a mechanism to detech dead OSPF neighbors > over demand circuits. > > Abhay Roy wrote: > > Mitchell, > > > > Please see some comments inline.. > > > > > >>>Date: Wed, 28 May 2003 11:52:47 -0700 > >>>From: Erblichs > >>>To: OSPF@PEACH.EASE.LSOFT.COM, iesg@ietf.org > >>>References: > >>> > >>>Ok, > >>> > >>> If I wanted to look into the draft itself, then I have 4 suggestions > >>> labed A, B, C, and D. > >>> > >>> A) No order is implied.. > >>> 2. "When application traffic starts going over the link, the > >>> link is brought up, and the routers may probe each other." > >>> > >>> The wording could be improved to specify: > >>> > >>> After the link is brought up, a probe SHOULD be sent if ..ProbeInterval > >>> has expired, and after verifying a successful probe, then application > >>> data can be sent. > >> > > > > We can change MAY to a SHOULD. > > > > The latter part implies that the data should not be sent till the > > probe succeeds.. I don't think there is any need to be that > > extreme. The success of probes depends on possibly retransmitting > > the Update packet multiple times. And I don't see much value > > (except maybe in the case, when the neighbor is indeed dead) in > > dropping the data for that much time. > > > > > >>> B) Configurable Parameters > >>> > >>> Did I see any usage of these parameters in the draft? Shouldn't > >>> some wording be used for them in the draft before the > >>> appendix? > >> > > > > We got the same comment from the AD ;) We will fix it.. > > > > > >>> C) ...ProbeInterval > >>> > >>> I question whether a sucessful probe that is specified in this > >>> draft will guarantee that even with link that is up that application > >>> traffic will be properly recieved. > >>> > >>> Why? A probe with a minimum packet/frame size may succeed in > >>> a buffer allocation where application traffic may use a MTU > >>> size packet. Thus, probes should be of MTU size. > >>> (this type of verification is done in IS-IS) > >>> > >>> Thus, I would add a suggested probe size of MTU size. > >> > > > > OSPF uses Interface MTU during DBD exchange to make sure that > > MTU's match.. If there was an MTU problem, the adjacency will not > > progress to FULL state.. The probe is just an OSPF update packet, > > so it has no size restrictions.. > > > > > >>> D) .. ProbeInterval > >>> > >>> I question that an demand link uptime can be shorter > >>> than ..ProbeInterval. In the event that ..ProbeInterval > >>> is longer than successive application transmissions, then > >>> some application traffic is sent without a prior probe. > >>> > >>> Thus, for the paranoid of us, I would expect that a probe be sent > >>> before and after application data. This would allow a higher > >>> assurance level of successful transmission of the application > >>> data. > >>> > >>> Thus, my suggestion is to remove the ..ProbeInterval config > >>> value and suggest bracketing application data with probes. > >>> > >>> My only issue, is if the first probe succeeded and the 2nd failed, > >>> then what do you do? > >>> > >>> Minimally, I would expect a probe before each application transmit > >>> and remove the ..ProbeInterval config value. > >> > > > > To me, the probe is just a background task to verify the viability > > of the DC link to a neighbor. I don't see how data plane waiting > > for control plane verification is going to help.. > > > > Regards, > > -Roy- > > > > > > > >>> Mitchell Erblich > >>> Sr Software Engineer > >>> ----------------------- > >>> > >>> > >>>>>The IESG wrote: > >>>>> > >>>>>>The IESG has received a request from the Open Shortest Path > >>>>>>First IGP Working Group to consider Detecting Inactive Neighbors > >>>>>>over OSPF Demand Circuits as a > >>>>>>Proposed Standard. > >>>>>> > >>>>>>The IESG plans to make a decision in the next few weeks, > >>>>> > >>>>>and solicits > >>>>> > >>>>>>final comments on this action. Please send any comments to the > >>>>>>iesg@ietf.org or ietf@ietf.org mailing lists by 2003-6-10. > >>>>>> > >>>>>>Files can be obtained > >>>>>>via http://www.ietf.org/internet-drafts/draft-ietf-ospf-dc-06.txt > >>>>> > >> > > > > -- > Acee From owner-ospf@PEACH.EASE.LSOFT.COM Wed May 28 21:35:04 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02297 for ; Wed, 28 May 2003 21:35:03 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.009EA8C4@cherry.ease.lsoft.com>; Wed, 28 May 2003 21:35:02 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 43990006 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 28 May 2003 21:35:01 -0400 Received: from 171.71.177.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 28 May 2003 21:35:01 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h4T1Yx9x008335 for ; Wed, 28 May 2003 18:34:59 -0700 (PDT) Received: from irp-view7.cisco.com (irp-view7.cisco.com [171.70.65.144]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AHO21631; Wed, 28 May 2003 18:32:06 -0700 (PDT) References: <3ED509DA.C7720CAB@earthlink.net> <3ED5298A.4040503@redback.com> <3ED54DE5.CE544E68@earthlink.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Wed, 28 May 2003 18:34:58 -0700 Reply-To: Mailing List Sender: Mailing List From: Abhay Roy Subject: Re: FW: Last Call: Detecting Inactive Neighbors over OSPF Demand To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <3ED54DE5.CE544E68@earthlink.net> Precedence: list Mitchell, In case of 'always up' DC links, it does turn out to be periodic probing. But in case of 'on demand' DC links, (if there is no data traffic) it's of no use to bring up the link just to send probes. So it makes sense to piggy back this event on the link coming up event, and keep doing it periodically till the time line remains up (due to data traffic). Regards, -Roy- On 05/28/03-0700 at 5:01pm, Erblichs writes: > Abhay Roy and Acee Lindem, > > If the mechanism is to detect only dead neighbors, > then why wouldn't their be just a periodic probing > of the neighbor every 45 minutes or so, without > respect to the application data traffic? > > In addition, if a probe is recieved and responded > to within the 1 hr time frame, then a probe in the > reverse direction would not be necessary until > the next time interval. > > If on the other hand it is important to know that > the data was successfully transmitted over the DC > (which infers a live nbr), then a verification of a > successful probe, in my opinion should proceed the > transmit of the application data. > > Lastly, my MTU size packet is not to verify that the > link-MTUs match between the two nbrs. It is to verify > that MTU size buffers are available for the incoming > application traffic. It is assumed that a MTU probe > length, will be of an insignificant amount of additional > data and processing overhead. > > Mitchell Erblich > Sr Software Engineer > ------------------- > > Acee Lindem wrote: > > > > I agree with Abhay on all points. Especially that we do not want > > to make this a mechanism to verify MTU agreement or verify the > > data plane. It is solely a mechanism to detech dead OSPF neighbors > > over demand circuits. > > > > Abhay Roy wrote: > > > Mitchell, > > > > > > Please see some comments inline.. > > > > > > > > >>>Date: Wed, 28 May 2003 11:52:47 -0700 > > >>>From: Erblichs > > >>>To: OSPF@PEACH.EASE.LSOFT.COM, iesg@ietf.org > > >>>References: > > >>> > > >>>Ok, > > >>> > > >>> If I wanted to look into the draft itself, then I have 4 suggestions > > >>> labed A, B, C, and D. > > >>> > > >>> A) No order is implied.. > > >>> 2. "When application traffic starts going over the link, the > > >>> link is brought up, and the routers may probe each other." > > >>> > > >>> The wording could be improved to specify: > > >>> > > >>> After the link is brought up, a probe SHOULD be sent if ..ProbeInterval > > >>> has expired, and after verifying a successful probe, then application > > >>> data can be sent. > > >> > > > > > > We can change MAY to a SHOULD. > > > > > > The latter part implies that the data should not be sent till the > > > probe succeeds.. I don't think there is any need to be that > > > extreme. The success of probes depends on possibly retransmitting > > > the Update packet multiple times. And I don't see much value > > > (except maybe in the case, when the neighbor is indeed dead) in > > > dropping the data for that much time. > > > > > > > > >>> B) Configurable Parameters > > >>> > > >>> Did I see any usage of these parameters in the draft? Shouldn't > > >>> some wording be used for them in the draft before the > > >>> appendix? > > >> > > > > > > We got the same comment from the AD ;) We will fix it.. > > > > > > > > >>> C) ...ProbeInterval > > >>> > > >>> I question whether a sucessful probe that is specified in this > > >>> draft will guarantee that even with link that is up that application > > >>> traffic will be properly recieved. > > >>> > > >>> Why? A probe with a minimum packet/frame size may succeed in > > >>> a buffer allocation where application traffic may use a MTU > > >>> size packet. Thus, probes should be of MTU size. > > >>> (this type of verification is done in IS-IS) > > >>> > > >>> Thus, I would add a suggested probe size of MTU size. > > >> > > > > > > OSPF uses Interface MTU during DBD exchange to make sure that > > > MTU's match.. If there was an MTU problem, the adjacency will not > > > progress to FULL state.. The probe is just an OSPF update packet, > > > so it has no size restrictions.. > > > > > > > > >>> D) .. ProbeInterval > > >>> > > >>> I question that an demand link uptime can be shorter > > >>> than ..ProbeInterval. In the event that ..ProbeInterval > > >>> is longer than successive application transmissions, then > > >>> some application traffic is sent without a prior probe. > > >>> > > >>> Thus, for the paranoid of us, I would expect that a probe be sent > > >>> before and after application data. This would allow a higher > > >>> assurance level of successful transmission of the application > > >>> data. > > >>> > > >>> Thus, my suggestion is to remove the ..ProbeInterval config > > >>> value and suggest bracketing application data with probes. > > >>> > > >>> My only issue, is if the first probe succeeded and the 2nd failed, > > >>> then what do you do? > > >>> > > >>> Minimally, I would expect a probe before each application transmit > > >>> and remove the ..ProbeInterval config value. > > >> > > > > > > To me, the probe is just a background task to verify the viability > > > of the DC link to a neighbor. I don't see how data plane waiting > > > for control plane verification is going to help.. > > > > > > Regards, > > > -Roy- > > > > > > > > > > > >>> Mitchell Erblich > > >>> Sr Software Engineer > > >>> ----------------------- > > >>> > > >>> > > >>>>>The IESG wrote: > > >>>>> > > >>>>>>The IESG has received a request from the Open Shortest Path > > >>>>>>First IGP Working Group to consider Detecting Inactive Neighbors > > >>>>>>over OSPF Demand Circuits as a > > >>>>>>Proposed Standard. > > >>>>>> > > >>>>>>The IESG plans to make a decision in the next few weeks, > > >>>>> > > >>>>>and solicits > > >>>>> > > >>>>>>final comments on this action. Please send any comments to the > > >>>>>>iesg@ietf.org or ietf@ietf.org mailing lists by 2003-6-10. > > >>>>>> > > >>>>>>Files can be obtained > > >>>>>>via http://www.ietf.org/internet-drafts/draft-ietf-ospf-dc-06.txt > > >>>>> > > >> > > > > > > > -- > > Acee > From owner-ospf@PEACH.EASE.LSOFT.COM Thu May 29 01:32:05 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07759 for ; Thu, 29 May 2003 01:32:04 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.009EB05F@cherry.ease.lsoft.com>; Thu, 29 May 2003 1:32:03 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 44014629 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 29 May 2003 01:32:01 -0400 Received: from 216.136.172.36 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 29 May 2003 01:22:01 -0400 Received: from [129.110.39.39] by web11504.mail.yahoo.com via HTTP; Wed, 28 May 2003 22:22:00 PDT MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1316695039-1054185720=:91631" Message-ID: <20030529052200.91783.qmail@web11504.mail.yahoo.com> Date: Wed, 28 May 2003 22:22:00 -0700 Reply-To: Mailing List Sender: Mailing List From: avinash gupta Subject: Unregister me from this group To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <3ED4F4A3.E6399115@earthlink.net> Precedence: list --0-1316695039-1054185720=:91631 Content-Type: text/plain; charset=us-ascii Unregister me from this group --------------------------------- Do you Yahoo!? Free online calendar with sync to Outlook(TM). --0-1316695039-1054185720=:91631 Content-Type: text/html; charset=us-ascii

Unregister me from this group



Do you Yahoo!?
Free online calendar with sync to Outlook(TM). --0-1316695039-1054185720=:91631-- From owner-ospf@PEACH.EASE.LSOFT.COM Thu May 29 01:32:44 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07785 for ; Thu, 29 May 2003 01:32:44 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.009EB251@cherry.ease.lsoft.com>; Thu, 29 May 2003 1:32:43 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 44014634 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 29 May 2003 01:32:41 -0400 Received: from 216.136.172.40 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 29 May 2003 01:22:40 -0400 Received: from [129.110.39.39] by web11508.mail.yahoo.com via HTTP; Wed, 28 May 2003 22:22:40 PDT MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-98007970-1054185760=:41879" Message-ID: <20030529052240.42686.qmail@web11508.mail.yahoo.com> Date: Wed, 28 May 2003 22:22:40 -0700 Reply-To: Mailing List Sender: Mailing List From: avinash gupta Subject: Unregister me from this group To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list --0-98007970-1054185760=:41879 Content-Type: text/plain; charset=us-ascii Unregister me from this group --------------------------------- Do you Yahoo!? Free online calendar with sync to Outlook(TM). --0-98007970-1054185760=:41879 Content-Type: text/html; charset=us-ascii
Unregister me from this group


Do you Yahoo!?
Free online calendar with sync to Outlook(TM). --0-98007970-1054185760=:41879-- From owner-ospf@PEACH.EASE.LSOFT.COM Thu May 29 05:53:23 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24546 for ; Thu, 29 May 2003 05:53:23 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.009EB61F@cherry.ease.lsoft.com>; Thu, 29 May 2003 5:53:22 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 44020462 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 29 May 2003 05:53:21 -0400 Received: from 207.68.165.20 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 29 May 2003 05:53:21 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 29 May 2003 02:53:20 -0700 Received: from 203.197.142.162 by sea2fd.sea2.hotmail.msn.com with HTTP; Thu, 29 May 2003 09:53:20 GMT X-Originating-IP: [203.197.142.162] X-Originating-Email: [mohitgurnani@hotmail.com] Mime-Version: 1.0 Content-Type: text/html X-OriginalArrivalTime: 29 May 2003 09:53:20.0774 (UTC) FILETIME=[23054260:01C325C8] Message-ID: Date: Thu, 29 May 2003 15:23:20 +0530 Reply-To: Mailing List Sender: Mailing List From: mohit gurnani Subject: Unregister me from this mailgroup To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list
Unregister me from this mailgroup

Staying fit. It's about being happy! Check out the new mantra From owner-ospf@PEACH.EASE.LSOFT.COM Fri May 30 03:19:11 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22438 for ; Fri, 30 May 2003 03:19:11 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.009ED618@cherry.ease.lsoft.com>; Fri, 30 May 2003 3:19:09 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 44132884 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 30 May 2003 03:19:08 -0400 Received: from 207.217.120.120 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 30 May 2003 03:19:08 -0400 Received: from user-38lc14i.dialup.mindspring.com ([209.86.4.146] helo=earthlink.net) by albatross.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 19LeAN-0003RY-00 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 30 May 2003 00:19:07 -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: <3ED509DA.C7720CAB@earthlink.net> <3ED516E3.35CF71BB@earthlink.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3ED7062A.B5B24249@earthlink.net> Date: Fri, 30 May 2003 00:20:10 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: FW: Last Call: Detecting Inactive Neighbors over OSPF Demand To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Lets cover two stones with one throw.. Lets try part of this again.. In the 1793 RFC which deals with demand circuits, there is a 2.3 - 2) section that mentions MaxAge seconds, aka 3600 seconds or 1 hr. To ensure that these LSAs are eventually flushed from the routing domain, and that the size of the link state database doesn't grow without bound, routers are required to flush a DoNotAge LSA if BOTH of the following conditions are met: (2) The originator of the LSA has been unreachable (according to the routing calculations specified by Section 16 of [1]) for at least MaxAge seconds. If probe exceeds 1 hr then LSAs are most likely dropped and LSAs need to be originated. Thus, tell me why you would want to allow LSAs to be forced to be re-originated in favor of a longer probe. I also think you may get a dead nbr, but that is a different discussion point.. Mitchell Erblich Sr Software Engineer --------------------- Mitchell, In case of 'always up' DC links, it does turn out to be periodic probing. But in case of 'on demand' DC links, (if there is no data traffic) it's of no use to bring up the link just to send probes. So it makes sense to piggy back this event on the link coming up event, and keep doing it periodically till the time line remains up (due to data traffic). Regards, -Roy- Abhay Roy wrote: > > Mitchell, > > Why it MUST not exceed 1hr? Today it's infinity, so in theory any > interval (including absurdly high ones) should be allowed. > > Regards, > -Roy- > > On 05/28/03-0700 at 1:06pm, Erblichs writes: > > > Sorry group, > > > > I forgot.. > > > > E) If ..ProbeInterval is kept, its max value MUST not exceed > > 1 hr.. > > > > I think this follows that if we haven't heard from our > > nbr in 1 hr "he" is considered dead. > > > > Mitchell Erblich > > ------------------- From owner-ospf@PEACH.EASE.LSOFT.COM Fri May 30 03:47:50 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23646 for ; Fri, 30 May 2003 03:47:48 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.009ED7A2@cherry.ease.lsoft.com>; Fri, 30 May 2003 3:47:48 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 44133093 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 30 May 2003 03:47:45 -0400 Received: from 66.218.93.118 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 30 May 2003 03:47:44 -0400 Received: from [64.95.122.13] by web41701.mail.yahoo.com via HTTP; Fri, 30 May 2003 00:47:44 PDT MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-2041082466-1054280864=:59328" Message-ID: <20030530074744.61656.qmail@web41701.mail.yahoo.com> Date: Fri, 30 May 2003 00:47:44 -0700 Reply-To: Mailing List Sender: Mailing List From: somnath mani Subject: NSSA forwarding address To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list --0-2041082466-1054280864=:59328 Content-Type: text/plain; charset=us-ascii Folks, The RFC for NSSA states that we set the forwarding address in a type 7 LSA to be that of any interface on which OSPF is configured ( barring the scenario, when the interface to the other AS is internal to OSPF). This is a problem when you are trying to do equal cost multipath routing and in some other situations. Consider a router A with 2 interfaces configured to run OSPF, IF1 and IF2. The cost on both these interfaces is 10 , let's say. If we pick the forwarding address to be IF2 ( We are redistributing at router A), then a router B adjacent to A over IF1 will compute the cost for a type 7 LSA route to be 10 + 10 = 20 ( Assume either ends of the interfaces are configured with same cost). Whereas, router C, adjacent to router A over IF2 will compute the same to be 10 !! Routers upstream of Router B and C will prefer to route via C ! Would it not be better if we set the forwarding address to be the router ID ( provided we have added it as a stub host ) ? Thanks Somnath --------------------------------- Do you Yahoo!? Free online calendar with sync to Outlook(TM). --0-2041082466-1054280864=:59328 Content-Type: text/html; charset=us-ascii
Folks,
The RFC for NSSA states that we set the forwarding address in a type 7 LSA to be that of any interface on which OSPF is configured ( barring the scenario, when the interface to the other AS is internal to OSPF).
This is a problem when you are trying to do equal cost multipath routing and in some other situations.
 
Consider a router A with 2 interfaces configured to run OSPF, IF1 and IF2. The cost on both these interfaces is 10 , let's say.
 
If we pick the forwarding address to be IF2 ( We are redistributing at router A), then a router B adjacent to A over IF1 will compute the cost for a type 7 LSA route to be 10 + 10 = 20 ( Assume either ends of the interfaces are configured with same cost). Whereas, router C, adjacent to router A over IF2 will compute the same to be 10 !!
 
Routers upstream of Router B and C will prefer to route via C !
 
Would it not be better if we set the forwarding address to be the router ID ( provided we have added it as a stub host ) ?
 
Thanks
Somnath
 
 

Do you Yahoo!?
Free online calendar with sync to Outlook(TM). --0-2041082466-1054280864=:59328-- From owner-ospf@PEACH.EASE.LSOFT.COM Fri May 30 04:35:46 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25136 for ; Fri, 30 May 2003 04:35:46 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.009ED7EB@cherry.ease.lsoft.com>; Fri, 30 May 2003 4:35:45 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 44134151 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 30 May 2003 04:35:44 -0400 Received: from 171.71.177.237 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 30 May 2003 04:35:44 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h4U8ZgFW023059 for ; Fri, 30 May 2003 01:35:42 -0700 (PDT) Received: from irp-view7.cisco.com (irp-view7.cisco.com [171.70.65.144]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AHP56974; Fri, 30 May 2003 01:32:38 -0700 (PDT) References: <3ED509DA.C7720CAB@earthlink.net> <3ED516E3.35CF71BB@earthlink.net> <3ED7062A.B5B24249@earthlink.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Fri, 30 May 2003 01:35:41 -0700 Reply-To: Mailing List Sender: Mailing List From: Abhay Roy Subject: Re: FW: Last Call: Detecting Inactive Neighbors over OSPF Demand To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <3ED7062A.B5B24249@earthlink.net> Precedence: list Mitchell, The important point to note here is that: If the originator is 'reachable', DoNotAge LSA's can stay forever. Regards, -Roy- On 05/30/03-0700 at 12:20am, Erblichs writes: > Lets cover two stones with one throw.. > > Lets try part of this again.. > > In the 1793 RFC which deals with demand circuits, > there is a 2.3 - 2) section that mentions MaxAge > seconds, aka 3600 seconds or 1 hr. > > To ensure that these LSAs are eventually > flushed from the routing domain, and that the size of the link > state database doesn't grow without bound, routers are required to > flush a DoNotAge LSA if BOTH of the following conditions are met: > > (2) The originator of the LSA has been unreachable (according to > the routing calculations specified by Section 16 of [1]) for > at least MaxAge seconds. > > If probe exceeds 1 hr then LSAs are most likely > dropped and LSAs need to be originated. Thus, tell > me why you would want to allow LSAs to be forced > to be re-originated in favor of a longer probe. > > I also think you may get a dead nbr, but that is > a different discussion point.. > > Mitchell Erblich > Sr Software Engineer > --------------------- > > > Mitchell, > > In case of 'always up' DC links, it does turn out to be periodic > probing. But in case of 'on demand' DC links, (if there is no data > traffic) it's of no use to bring up the link just to send probes. > So it makes sense to piggy back this event on the link coming up > event, and keep doing it periodically till the time line remains > up (due to data traffic). > > Regards, > -Roy- > > > > Abhay Roy wrote: > > > > Mitchell, > > > > Why it MUST not exceed 1hr? Today it's infinity, so in theory any > > interval (including absurdly high ones) should be allowed. > > > > Regards, > > -Roy- > > > > On 05/28/03-0700 at 1:06pm, Erblichs writes: > > > > > Sorry group, > > > > > > I forgot.. > > > > > > E) If ..ProbeInterval is kept, its max value MUST not exceed > > > 1 hr.. > > > > > > I think this follows that if we haven't heard from our > > > nbr in 1 hr "he" is considered dead. > > > > > > Mitchell Erblich > > > ------------------- > From owner-ospf@PEACH.EASE.LSOFT.COM Fri May 30 07:25:36 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29142 for ; Fri, 30 May 2003 07:25:36 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.009EDA4B@cherry.ease.lsoft.com>; Fri, 30 May 2003 7:25:34 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 44151210 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 30 May 2003 07:25:33 -0400 Received: from 209.119.0.109 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 30 May 2003 07:15:33 -0400 Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.009ED870@cherry.ease.lsoft.com>; Fri, 30 May 2003 7:15:33 -0400 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 30 May 2003 07:15:32 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28550; Fri, 30 May 2003 07:15:29 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200305301115.HAA28550@ietf.org> Date: Fri, 30 May 2003 07:15:29 -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-05.txt Comments: cc: ospf@discuss.microsoft.com To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF. Title : Prioritized Treatment of Specific OSPF Packets and Congestion Avoidance Author(s) : G. Choudhury et al. Filename : draft-ietf-ospf-scalability-05.txt Pages : 18 Date : 2003-5-29 This document recommends methods that are intended to improve the scalability and stability of large networks using OSPF (Open Shortest Path First) protocol. The methods include processing OSPF Hellos and LSA (Link State Advertisement) Acknowledgments at a higher priority compared to other OSPF packets, and other congestion avoidance procedures. Simulation results in support of some of the recommendations are given in the appendix sections. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-scalability-05.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-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ospf-scalability-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-5-29161847.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ospf-scalability-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ospf-scalability-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-29161847.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@PEACH.EASE.LSOFT.COM Fri May 30 07:27:06 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29195 for ; Fri, 30 May 2003 07:27:06 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.009EDA64@cherry.ease.lsoft.com>; Fri, 30 May 2003 7:27:05 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 44151496 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 30 May 2003 07:27:04 -0400 Received: from 203.199.83.27 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 30 May 2003 07:27:03 -0400 Received: (qmail 31549 invoked by uid 510); 30 May 2003 11:27:01 -0000 Received: from unknown (203.197.138.201) by rediffmail.com via HTTP; 30 may 2003 11:27:01 -0000 MIME-Version: 1.0 Content-type: text/plain; format=flowed Content-Disposition: inline Message-ID: <20030530112701.31548.qmail@webmail17.rediffmail.com> Date: Fri, 30 May 2003 11:27:01 -0000 Reply-To: Mailing List Sender: Mailing List From: Vivek Dubey Subject: Re: NSSA forwarding address To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Hi Somnath, RFC preference rule for picking Fwd addr 1) If the network between the NSSA AS boundary router and the adjacent AS is advertised into OSPF as an internal OSPF route (choose next hop) 2) Loop back interface 3) NSSA interface 4) Stub interface From what i understood from your mail : if you choose loop back address problem scenarion will not occur. vivek On Fri, 30 May 2003 somnath mani wrote : >Folks, >The RFC for NSSA states that we set the forwarding address in a >type 7 LSA to be that of any interface on which OSPF is >configured ( barring the scenario, when the interface to the >other AS is internal to OSPF). >This is a problem when you are trying to do equal cost multipath >routing and in some other situations. > >Consider a router A with 2 interfaces configured to run OSPF, IF1 >and IF2. The cost on both these interfaces is 10 , let's say. > >If we pick the forwarding address to be IF2 ( We are >redistributing at router A), then a router B adjacent to A over >IF1 will compute the cost for a type 7 LSA route to be 10 + 10 = >20 ( Assume either ends of the interfaces are configured with >same cost). Whereas, router C, adjacent to router A over IF2 will >compute the same to be 10 !! > >Routers upstream of Router B and C will prefer to route via C ! > >Would it not be better if we set the forwarding address to be the >router ID ( provided we have added it as a stub host ) ? > >Thanks >Somnath > > > > >--------------------------------- >Do you Yahoo!? >Free online calendar with sync to Outlook(TM). ___________________________________________________ Get email that means BUSINESS! me @ mycompany.com. Just Rs.1499/year. To start, click http://www.rediffmailpro.com From owner-ospf@PEACH.EASE.LSOFT.COM Fri May 30 10:22:22 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10069 for ; Fri, 30 May 2003 10:22:22 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.009EDC97@cherry.ease.lsoft.com>; Fri, 30 May 2003 10:22:22 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 44161884 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 30 May 2003 10:22:20 -0400 Received: from 204.192.44.242 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 30 May 2003 10:22:20 -0400 Received: (qmail 19973 invoked from network); 30 May 2003 14:22:20 -0000 Received: from bigbird.xebeo.com (192.168.0.21) by lxmail.xebeo.com with SMTP; 30 May 2003 14:22:20 -0000 Received: from bigbird.xebeo.com (localhost.localdomain [127.0.0.1]) by bigbird.xebeo.com (8.9.3/8.9.3) with ESMTP id KAA11165 for ; Fri, 30 May 2003 10:22:20 -0400 X-Mailer: exmh version 2.1.1 10/15/1999 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <200305301422.KAA11165@bigbird.xebeo.com> Date: Fri, 30 May 2003 10:22:20 -0400 Reply-To: Mailing List Sender: Mailing List From: Rohit Dube Subject: Working Group Last Call for draft-ietf-ospf-scalability-05.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This is the start of a Working Group last call for Prioritized Treatment of Specific OSPF Packets and Congestion Avoidance (draft-ietf-ospf-scalability-05.txt). All comments be received by Friday, June 13, 2003. The draft can be found at http://www.ietf.org/internet-drafts/draft-ietf-ospf-scalability-05.txt --rohit. From owner-ospf@PEACH.EASE.LSOFT.COM Fri May 30 11:18:59 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12771 for ; Fri, 30 May 2003 11:18:58 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.009EDD9E@cherry.ease.lsoft.com>; Fri, 30 May 2003 11:18:59 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 44166697 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 30 May 2003 11:18:58 -0400 Received: from 203.197.140.35 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 30 May 2003 11:18:56 -0400 Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Fri, 30 May 2003 20:58:32 +0530 Received: from vivekd (vivekd.future.futsoft.com [10.20.6.77]) by kailash.future.futsoft.com (8.12.2/8.12.2) with SMTP id h4UFEGqE017230 for ; Fri, 30 May 2003 20:44:16 +0530 MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-ID: <000a01c326be$c97781c0$4d06140a@future.futsoft.com> Date: Fri, 30 May 2003 20:48:55 +0530 Reply-To: Mailing List Sender: Mailing List From: Vivek Dubey Subject: Re: FW: Last Call: Detecting Inactive Neighbors over OSPF Demand To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit Roy, Suppose the time "Nbr probing" starts, the Ospf at the other end is undergoing "graceful restart"...(grace period 1800 sec)..... while probing fails at this end..... should we consdier NBR dead or there is some "safeguard" in RFC 1793 - graceful restart - and Nbr probing draft, for such scenario. thanks, vivek -----Original Message----- From: Mailing List [mailto:OSPF@peach.ease.lsoft.com]On Behalf Of Abhay Roy Sent: Friday, 30 May 2003 2:06 PM To: OSPF@peach.ease.lsoft.com Subject: Re: FW: Last Call: Detecting Inactive Neighbors over OSPF Demand Mitchell, The important point to note here is that: If the originator is 'reachable', DoNotAge LSA's can stay forever. Regards, -Roy- On 05/30/03-0700 at 12:20am, Erblichs writes: > Lets cover two stones with one throw.. > > Lets try part of this again.. > > In the 1793 RFC which deals with demand circuits, > there is a 2.3 - 2) section that mentions MaxAge > seconds, aka 3600 seconds or 1 hr. > > To ensure that these LSAs are eventually > flushed from the routing domain, and that the size of the link > state database doesn't grow without bound, routers are required to > flush a DoNotAge LSA if BOTH of the following conditions are met: > > (2) The originator of the LSA has been unreachable (according to > the routing calculations specified by Section 16 of [1]) for > at least MaxAge seconds. > > If probe exceeds 1 hr then LSAs are most likely > dropped and LSAs need to be originated. Thus, tell > me why you would want to allow LSAs to be forced > to be re-originated in favor of a longer probe. > > I also think you may get a dead nbr, but that is > a different discussion point.. > > Mitchell Erblich > Sr Software Engineer > --------------------- > > > Mitchell, > > In case of 'always up' DC links, it does turn out to be periodic > probing. But in case of 'on demand' DC links, (if there is no data > traffic) it's of no use to bring up the link just to send probes. > So it makes sense to piggy back this event on the link coming up > event, and keep doing it periodically till the time line remains > up (due to data traffic). > > Regards, > -Roy- > > > > Abhay Roy wrote: > > > > Mitchell, > > > > Why it MUST not exceed 1hr? Today it's infinity, so in theory any > > interval (including absurdly high ones) should be allowed. > > > > Regards, > > -Roy- > > > > On 05/28/03-0700 at 1:06pm, Erblichs writes: > > > > > Sorry group, > > > > > > I forgot.. > > > > > > E) If ..ProbeInterval is kept, its max value MUST not exceed > > > 1 hr.. > > > > > > I think this follows that if we haven't heard from our > > > nbr in 1 hr "he" is considered dead. > > > > > > Mitchell Erblich > > > ------------------- > *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** From owner-ospf@PEACH.EASE.LSOFT.COM Fri May 30 11:30:23 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13179 for ; Fri, 30 May 2003 11:30:23 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.009EDD16@cherry.ease.lsoft.com>; Fri, 30 May 2003 11:30:22 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 44167411 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 30 May 2003 11:30:21 -0400 Received: from 24.93.67.84 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 30 May 2003 11:30:21 -0400 Received: from redback.com (rdu163-33-198.nc.rr.com [24.163.33.198]) by ms-smtp-03.southeast.rr.com (8.12.5/8.12.2) with ESMTP id h4UFSitL020165 for ; Fri, 30 May 2003 11:28:44 -0400 (EDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <3ED509DA.C7720CAB@earthlink.net> <3ED516E3.35CF71BB@earthlink.net> <3ED7062A.B5B24249@earthlink.net> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3ED77888.2040301@redback.com> Date: Fri, 30 May 2003 11:28:08 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: FW: Last Call: Detecting Inactive Neighbors over OSPF Demand To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Another important point is that with the standard RFC 1793 behavior an adjacency over a DC link will stay up indefinitely. So this is an improvement no matter what the configured interval. Since the probing is disabled by default it is somewhat contradictory to put an upper limit on the probe interval (i.e., the default probing interval is infinite ;^). One could add a statement to the ospfIfDemandNbrProbeInterval description saying. "An interval of less than 3600 minutes is recommended to assure the stale DoNotAge LSAs are purged from the link state database." However, I'm not sure that this adds all that much value and would leave it to the discretion of the authors. Thanks, Acee Abhay Roy wrote: > Mitchell, > > The important point to note here is that: If the originator is > 'reachable', DoNotAge LSA's can stay forever. > > Regards, > -Roy- > > On 05/30/03-0700 at 12:20am, Erblichs writes: > > >>Lets cover two stones with one throw.. >> >> Lets try part of this again.. >> >> In the 1793 RFC which deals with demand circuits, >> there is a 2.3 - 2) section that mentions MaxAge >> seconds, aka 3600 seconds or 1 hr. >> >>To ensure that these LSAs are eventually >> flushed from the routing domain, and that the size of the link >> state database doesn't grow without bound, routers are required to >> flush a DoNotAge LSA if BOTH of the following conditions are met: >> >>(2) The originator of the LSA has been unreachable (according to >> the routing calculations specified by Section 16 of [1]) for >> at least MaxAge seconds. >> >> If probe exceeds 1 hr then LSAs are most likely >> dropped and LSAs need to be originated. Thus, tell >> me why you would want to allow LSAs to be forced >> to be re-originated in favor of a longer probe. >> >> I also think you may get a dead nbr, but that is >> a different discussion point.. >> >> Mitchell Erblich >> Sr Software Engineer >> --------------------- >> >> >>Mitchell, >> >>In case of 'always up' DC links, it does turn out to be periodic >>probing. But in case of 'on demand' DC links, (if there is no data >>traffic) it's of no use to bring up the link just to send probes. >>So it makes sense to piggy back this event on the link coming up >>event, and keep doing it periodically till the time line remains >>up (due to data traffic). >> >>Regards, >>-Roy- >> >> >> >>Abhay Roy wrote: >> >>>Mitchell, >>> >>>Why it MUST not exceed 1hr? Today it's infinity, so in theory any >>>interval (including absurdly high ones) should be allowed. >>> >>>Regards, >>>-Roy- >>> >>>On 05/28/03-0700 at 1:06pm, Erblichs writes: >>> >>> >>>>Sorry group, >>>> >>>> I forgot.. >>>> >>>> E) If ..ProbeInterval is kept, its max value MUST not exceed >>>> 1 hr.. >>>> >>>> I think this follows that if we haven't heard from our >>>> nbr in 1 hr "he" is considered dead. >>>> >>>> Mitchell Erblich >>>> ------------------- >>> > -- Acee From owner-ospf@PEACH.EASE.LSOFT.COM Fri May 30 11:31:07 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13260 for ; Fri, 30 May 2003 11:31:07 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.009EDD1B@cherry.ease.lsoft.com>; Fri, 30 May 2003 11:31:07 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 44167482 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 30 May 2003 11:31:06 -0400 Received: from 130.118.4.3 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 30 May 2003 11:31:06 -0400 Received: from omega7.wr.usgs.gov by omega7.wr.usgs.gov (PMDF V6.0-24 #41392) id <01KWHVJOYJ9C8X29XX@omega7.wr.usgs.gov> for OSPF@PEACH.EASE.LSOFT.COM; Fri, 30 May 2003 08:31:04 -0700 (PDT) X-VMS-To: OSPF@PEACH.EASE.LSOFT.COM X-VMS-Cc: PMURPHY MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Message-ID: <01KWHVJOYL4Y8X29XX@omega7.wr.usgs.gov> Date: Fri, 30 May 2003 08:31:04 -0700 Reply-To: Mailing List Sender: Mailing List From: "Pat Murphy - (650)329-4044" Subject: Re: NSSA forwarding address To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list NSSA RFC3101, states Normally the next hop address of an installed AS external route learned by an NSSA ASBR from an adjacent AS points at one of the adjacent AS's gateway routers. If this address belongs to a network connected to the NSSA ASBR via one of its NSSAs' active interfaces, then the NSSA ASBR copies this next hop address into the forwarding address field of the route's Type-7 LSA that is originated into this NSSA, as is currently done with Type-5 LSAs.... ...For an NSSA with no such network the forwarding address field may only be filled with an address from one of the its active interfaces or 0.0.0.0. Note in both cases the address must be chosen from one of the NSSA's networks. This always applies. If no such address is available, 0.0.0.0 must be used and the P-bit must be clear. When forced to chose an address from one of "the NSSA's active interfaces", the preference is 1) Loop back interface 2) Stub interface 3) Any remaining interface In all cases the network containing the non-zero forwarding address of a Type 7 LSA must be part of the NSSA. By the way it looks like the IETF OSPF WG page needs its Mailing Lists updated. Pat From owner-ospf@PEACH.EASE.LSOFT.COM Fri May 30 13:21:49 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17588 for ; Fri, 30 May 2003 13:21:49 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.009EE12D@cherry.ease.lsoft.com>; Fri, 30 May 2003 13:21:48 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 44177128 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 30 May 2003 13:21:46 -0400 Received: from 207.217.120.46 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 30 May 2003 13:21:46 -0400 Received: from user-2ivfjbn.dialup.mindspring.com ([165.247.205.119] helo=earthlink.net) by grebe.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 19LnZY-0002Pt-00 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 30 May 2003 10:21: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 References: <3ED509DA.C7720CAB@earthlink.net> <3ED516E3.35CF71BB@earthlink.net> <3ED7062A.B5B24249@earthlink.net> <3ED77888.2040301@redback.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3ED7934E.68E18ECD@earthlink.net> Date: Fri, 30 May 2003 10:22:22 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: FW: Last Call: Detecting Inactive Neighbors over OSPF Demand To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Abhay, Actually, I would say, if the originator is constantly "1 hr monotonomicly reachable", then DNA LSAs can stay forever in the LS tables. Acee Lindem, Interesting I always thought that either active (sending) or a passive (recieving) probing was a requirement for an active DC OSPF speaker. I classify DC nbrs that don't meet this criteria for 1 hr, .... (Sorry, Intellectural property and is extraneous information) :-) Lets work with your 2nd paragraph. Lets assume that the nbr can not be probed for over 1 hr and does not initiate a probe for over 1 hr. And that all its interfaces are DC based. Is it still a valid OSPF active speaker if the only entries in its link state tables are its own? Remember everything else is flushed. Why would OSPF want to allow this level of depricated implimentation? Doesn't it just consume nbr slots forever? Why wouldn't you want to explicitly state about stale LSAs? How many non OSPF developers realize the consequences of 1 hr plus probes. Mitchell Erblich Sr Software Engineer -------------------- Acee Lindem wrote: > > Another important point is that with the standard RFC 1793 behavior > an adjacency over a DC link will stay up indefinitely. So this > is an improvement no matter what the configured interval. Since > the probing is disabled by default it is somewhat contradictory > to put an upper limit on the probe interval (i.e., the default > probing interval is infinite ;^). > > One could add a statement to the ospfIfDemandNbrProbeInterval > description saying. "An interval of less than 3600 minutes is > recommended to assure the stale DoNotAge LSAs are purged from the > link state database." However, I'm not sure that this adds all > that much value and would leave it to the discretion of the > authors. > > Thanks, > Acee > > Abhay Roy wrote: > > Mitchell, > > > > The important point to note here is that: If the originator is > > 'reachable', DoNotAge LSA's can stay forever. > > > > Regards, > > -Roy- > > > > On 05/30/03-0700 at 12:20am, Erblichs writes: > > > > > >>Lets cover two stones with one throw.. > >> > >> Lets try part of this again.. > >> > >> In the 1793 RFC which deals with demand circuits, > >> there is a 2.3 - 2) section that mentions MaxAge > >> seconds, aka 3600 seconds or 1 hr. > >> > >>To ensure that these LSAs are eventually > >> flushed from the routing domain, and that the size of the link > >> state database doesn't grow without bound, routers are required to > >> flush a DoNotAge LSA if BOTH of the following conditions are met: > >> > >>(2) The originator of the LSA has been unreachable (according to > >> the routing calculations specified by Section 16 of [1]) for > >> at least MaxAge seconds. > >> > >> If probe exceeds 1 hr then LSAs are most likely > >> dropped and LSAs need to be originated. Thus, tell > >> me why you would want to allow LSAs to be forced > >> to be re-originated in favor of a longer probe. > >> > >> I also think you may get a dead nbr, but that is > >> a different discussion point.. > >> > >> Mitchell Erblich > >> Sr Software Engineer > >> --------------------- > >> > >> > >>Mitchell, > >> > >>In case of 'always up' DC links, it does turn out to be periodic > >>probing. But in case of 'on demand' DC links, (if there is no data > >>traffic) it's of no use to bring up the link just to send probes. > >>So it makes sense to piggy back this event on the link coming up > >>event, and keep doing it periodically till the time line remains > >>up (due to data traffic). > >> > >>Regards, > >>-Roy- > >> > >> > >> > >>Abhay Roy wrote: > >> > >>>Mitchell, > >>> > >>>Why it MUST not exceed 1hr? Today it's infinity, so in theory any > >>>interval (including absurdly high ones) should be allowed. > >>> > >>>Regards, > >>>-Roy- > >>> > >>>On 05/28/03-0700 at 1:06pm, Erblichs writes: > >>> > >>> > >>>>Sorry group, > >>>> > >>>> I forgot.. > >>>> > >>>> E) If ..ProbeInterval is kept, its max value MUST not exceed > >>>> 1 hr.. > >>>> > >>>> I think this follows that if we haven't heard from our > >>>> nbr in 1 hr "he" is considered dead. > >>>> > >>>> Mitchell Erblich > >>>> ------------------- > >>> > > > > -- > Acee From owner-ospf@PEACH.EASE.LSOFT.COM Fri May 30 15:12:58 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23320 for ; Fri, 30 May 2003 15:12:58 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.009EE2F8@cherry.ease.lsoft.com>; Fri, 30 May 2003 15:12:57 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 44184083 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 30 May 2003 15:12:55 -0400 Received: from 147.28.0.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 30 May 2003 15:12:55 -0400 Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 19LpJ5-000Ohc-00; Fri, 30 May 2003 19:12:51 +0000 X-Mailer: The Bat! (v1.62i) Personal X-Priority: 3 (Normal) References: <3ED509DA.C7720CAB@earthlink.net> <3ED516E3.35CF71BB@earthlink.net> <3ED7062A.B5B24249@earthlink.net> <3ED77888.2040301@redback.com> <3ED7934E.68E18ECD@earthlink.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <119577854701.20030530121234@psg.com> Date: Fri, 30 May 2003 12:12:34 -0700 Reply-To: Mailing List Sender: Mailing List From: Alex Zinin Subject: Re: FW: Last Call: Detecting Inactive Neighbors over OSPF Demand Comments: To: Erblichs To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <3ED7934E.68E18ECD@earthlink.net> Precedence: list Content-Transfer-Encoding: 7bit Mitchell- Let me try to address some of your questions/concerns. Friday, May 30, 2003, 12:20:10 AM, Erblichs wrote: ... > If probe exceeds 1 hr then LSAs are most likely > dropped and LSAs need to be originated. Thus, tell > me why you would want to allow LSAs to be forced > to be re-originated in favor of a longer probe. Please note that the neighbor probing process and the LSA origination process are not coupled. Regardless of how often I decide to probe my neighbors, I will keep refreshing my LSAs as usual, the only difference is in the sequence number in the LSA that will be found in n'th and n+1'st probes. Friday, May 30, 2003, 10:22:22 AM, Erblichs wrote: > Abhay, > Actually, I would say, if the originator is > constantly "1 hr monotonomicly reachable", > then DNA LSAs can stay forever in the LS > tables. Correct, and this is how it is supposed to work. > Acee Lindem, > Interesting I always thought that > either active (sending) or a passive > (recieving) probing was a requirement > for an active DC OSPF speaker. Not really. 1793 is based on the notion of "assumption of reachability", which is quite important. With hello suppression enabled, after a full adjacency has been established, we assume that the neighbor is reachable unless we receive an explicit indication proving this assumption wrong. 1793 mentions one possible indication--failure of the dialer to reach the guy. The document in question introduces another--failure of the reliable flooding mechanism to deliver an LSA. > I classify DC nbrs that don't meet this > criteria for 1 hr, .... > (Sorry, Intellectural property and is > extraneous information) :-) It is definitely possible to have implementation-specific mechanisms that decide when to bring a DC neighbor down. Note though that your approach may result in loss of connectivity when a multi-point dialer (one with more than one next-hop-to-phone-num mappings) doesn't even try to dial some remote locations due to the lack of application traffic in that direction... > Lets work with your 2nd paragraph. > Lets assume that the nbr can not be probed for > over 1 hr and does not initiate a probe for > over 1 hr. And that all its interfaces are > DC based. We should be clear whether you mean "a nbr is not probed for over 1hr because of the ProbeInterval" or "a nbr does not reply to probes for over 1hr". The latter is an indication of unreachability and should be caught by ProbeRetxLimit. The former is completely normal. > Is it still a valid OSPF active speaker if > the only entries in its link state tables > are its own? Remember everything else is > flushed. If all links are DC, then all received LSAs will be DNA. Provided that the adjacencies are not brought down, I don't see how all other LSAs could be assumed to be flushed. However, regardless of the above point, it is absolutely normal for a DC-connected router to not hear from its neighbor for more than one hour, because there may be no application traffic going in its direction and no topology changes that should be communicated to it. So, yes, it is still a valid OSPF speaker. Keep the presumption of reachability in mind. > Why would OSPF want to allow this level of > depricated implimentation? Doesn't it > just consume nbr slots forever? See above about proving wrong assumption of reachability. > Why wouldn't you want to explicitly state > about stale LSAs? How many non OSPF > developers realize the consequences of > 1 hr plus probes. It is not clear to me what you are proposing to state about stale LSAs. Regards Alex From owner-ospf@PEACH.EASE.LSOFT.COM Fri May 30 15:47:25 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24935 for ; Fri, 30 May 2003 15:47:24 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.009EE3DA@cherry.ease.lsoft.com>; Fri, 30 May 2003 15:47:24 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 44186581 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 30 May 2003 15:47:22 -0400 Received: from 171.71.177.237 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 30 May 2003 15:47:22 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h4UJlKFW022487 for ; Fri, 30 May 2003 12:47:20 -0700 (PDT) Received: from irp-view7.cisco.com (irp-view7.cisco.com [171.70.65.144]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AHQ07557; Fri, 30 May 2003 12:44:11 -0700 (PDT) References: <000a01c326be$c97781c0$4d06140a@future.futsoft.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Fri, 30 May 2003 12:47:19 -0700 Reply-To: Mailing List Sender: Mailing List From: Abhay Roy Subject: Re: FW: Last Call: Detecting Inactive Neighbors over OSPF Demand To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <000a01c326be$c97781c0$4d06140a@future.futsoft.com> Precedence: list Vivek, Generally graceful restart techniques should finish well before the probe retries (configurable) are finished. If it does not, then yes, we will consider the neighbor dead. But it's not a big problem, because the adjacency will come right back up. I guess implementations could choose to factor in the grace period to 'delay' probes. Regards, -Roy- On 05/30/03+0530 at 8:48pm, Vivek Dubey writes: > Roy, > Suppose the time "Nbr probing" starts, the Ospf at the > other end is undergoing "graceful restart"...(grace period > 1800 sec)..... > while probing fails at this end..... > should we consdier NBR dead or there is some "safeguard" > in RFC 1793 - graceful restart - and Nbr probing draft, for such scenario. > > > > thanks, > vivek > > > > -----Original Message----- > From: Mailing List [mailto:OSPF@peach.ease.lsoft.com]On Behalf Of Abhay > Roy > Sent: Friday, 30 May 2003 2:06 PM > To: OSPF@peach.ease.lsoft.com > Subject: Re: FW: Last Call: Detecting Inactive Neighbors over OSPF > Demand > > > Mitchell, > > The important point to note here is that: If the originator is > 'reachable', DoNotAge LSA's can stay forever. > > Regards, > -Roy- > > On 05/30/03-0700 at 12:20am, Erblichs writes: > > > Lets cover two stones with one throw.. > > > > Lets try part of this again.. > > > > In the 1793 RFC which deals with demand circuits, > > there is a 2.3 - 2) section that mentions MaxAge > > seconds, aka 3600 seconds or 1 hr. > > > > To ensure that these LSAs are eventually > > flushed from the routing domain, and that the size of the link > > state database doesn't grow without bound, routers are required to > > flush a DoNotAge LSA if BOTH of the following conditions are met: > > > > (2) The originator of the LSA has been unreachable (according to > > the routing calculations specified by Section 16 of [1]) for > > at least MaxAge seconds. > > > > If probe exceeds 1 hr then LSAs are most likely > > dropped and LSAs need to be originated. Thus, tell > > me why you would want to allow LSAs to be forced > > to be re-originated in favor of a longer probe. > > > > I also think you may get a dead nbr, but that is > > a different discussion point.. > > > > Mitchell Erblich > > Sr Software Engineer > > --------------------- > > > > > > Mitchell, > > > > In case of 'always up' DC links, it does turn out to be periodic > > probing. But in case of 'on demand' DC links, (if there is no data > > traffic) it's of no use to bring up the link just to send probes. > > So it makes sense to piggy back this event on the link coming up > > event, and keep doing it periodically till the time line remains > > up (due to data traffic). > > > > Regards, > > -Roy- > > > > > > > > Abhay Roy wrote: > > > > > > Mitchell, > > > > > > Why it MUST not exceed 1hr? Today it's infinity, so in theory any > > > interval (including absurdly high ones) should be allowed. > > > > > > Regards, > > > -Roy- > > > > > > On 05/28/03-0700 at 1:06pm, Erblichs writes: > > > > > > > Sorry group, > > > > > > > > I forgot.. > > > > > > > > E) If ..ProbeInterval is kept, its max value MUST not exceed > > > > 1 hr.. > > > > > > > > I think this follows that if we haven't heard from our > > > > nbr in 1 hr "he" is considered dead. > > > > > > > > Mitchell Erblich > > > > ------------------- > > > > *************************************************************************** > This message is proprietary to Future Software Limited (FSL) > and is intended solely for the use of the individual to whom it > is addressed. It may contain privileged or confidential information > and should not be circulated or used for any purpose other than for > what it is intended. > > If you have received this message in error, please notify the > originator immediately. If you are not the intended recipient, > you are notified that you are strictly prohibited from using, > copying, altering, or disclosing the contents of this message. > FSL accepts no responsibility for loss or damage arising from > the use of the information transmitted by this email including > damage from virus. > *************************************************************************** > From owner-ospf@PEACH.EASE.LSOFT.COM Fri May 30 16:52:42 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27438 for ; Fri, 30 May 2003 16:52:42 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.009EE71C@cherry.ease.lsoft.com>; Fri, 30 May 2003 16:52:42 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 44190278 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 30 May 2003 16:52:40 -0400 Received: from 204.192.44.242 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 30 May 2003 16:52:40 -0400 Received: (qmail 17147 invoked from network); 30 May 2003 20:52:40 -0000 Received: from bigbird.xebeo.com (192.168.0.21) by lxmail.xebeo.com with SMTP; 30 May 2003 20:52:40 -0000 Received: from bigbird.xebeo.com (localhost.localdomain [127.0.0.1]) by bigbird.xebeo.com (8.9.3/8.9.3) with ESMTP id QAA29740 for ; Fri, 30 May 2003 16:52:40 -0400 X-Mailer: exmh version 2.1.1 10/15/1999 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <200305302052.QAA29740@bigbird.xebeo.com> Date: Fri, 30 May 2003 16:52:40 -0400 Reply-To: Mailing List Sender: Mailing List From: Rohit Dube Subject: ospf mailing list administrivia To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Folks, The ospf mailing list has moved as recent posters must have already realized. Existing subscribers remain on the new list. You can find information regarding the ospf mailing list at http://rtg.ietf.org/ospf/ (Many thanks to Bill Fenner for helping set up the page) BTW, the mailing list archive at http://peach.ease.lsoft.com/archives/ospf.html is not completely functional - many bodies for the messages posted cannot yet be accessed. David Whipple is working on this. We will send a message when that archive is fully functional. Patience... --rohit. From owner-ospf@PEACH.EASE.LSOFT.COM Fri May 30 17:25:32 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29019 for ; Fri, 30 May 2003 17:25:13 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.009EEA30@cherry.ease.lsoft.com>; Fri, 30 May 2003 17:25:13 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 44191515 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 30 May 2003 17:25:08 -0400 Received: from 207.217.120.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 30 May 2003 17:25:07 -0400 Received: from user-2ivfjbn.dialup.mindspring.com ([165.247.205.119] helo=earthlink.net) by snipe.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 19LrN3-0006ON-00 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 30 May 2003 14:25:06 -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: <3ED509DA.C7720CAB@earthlink.net> <3ED516E3.35CF71BB@earthlink.net> <3ED7062A.B5B24249@earthlink.net> <3ED77888.2040301@redback.com> <3ED7934E.68E18ECD@earthlink.net> <119577854701.20030530121234@psg.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3ED7CC53.13ECD3C2@earthlink.net> Date: Fri, 30 May 2003 14:25:39 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: FW: Last Call: Detecting Inactive Neighbors over OSPF Demand To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Alex, Alex, Just 3 Inlines.. And all of this is to suggest that a DC router in my opinion SHOULD send or recieve sucessful probes to/from each DC nbr within each monotomically hr. And that a successful probe will determine that a data-link is not closed and data will have a decent probably of being accepted. This does imply that the probe opens the connection, just that the connection is open at the time of the probe. Mitch or Mitchell --------- Alex Zinin wrote: > > Mitchell- > > > > Let me try to address some of your questions/concerns. > > Friday, May 30, 2003, 12:20:10 AM, Erblichs wrote: > ... > > If probe exceeds 1 hr then LSAs are most likely > > dropped and LSAs need to be originated. Thus, tell > > me why you would want to allow LSAs to be forced > > to be re-originated in favor of a longer probe. > > Please note that the neighbor probing process and the LSA origination > process are not coupled. Regardless of how often I decide to probe my > neighbors, I will keep refreshing my LSAs as usual, the only > difference is in the sequence number in the LSA that will be found > in n'th and n+1'st probes. > > Friday, May 30, 2003, 10:22:22 AM, Erblichs wrote: > > Abhay, > > > Actually, I would say, if the originator is > > constantly "1 hr monotonomicly reachable", > > then DNA LSAs can stay forever in the LS > > tables. > > Correct, and this is how it is supposed to work. If it is NOT, 1 hr REACHABLE, then DC DNA LSAs are flushed via rfc1793 2.3 - 2, in 1 hr time frame. This is specified specifly for DC router DNA LSAs, but will also occur for non-DNA LSAs, due to the fact of "reachability failure"., but will not allow updates to refresh non-DNA LSAs on the DC router, because.. "..., OSPF Hellos and the refresh of OSPF routing information are suppressed on demand circuits, allowing the underlying data-link connections to be closed when not carrying application traffic." thus, Do you really think a OSPF router that only has its own LSAs can be a valid OSPF router? Justify to me that this router is doing any good after the link has been down for 1hr or more? =============== ======================= > > Acee Lindem, > > > Interesting I always thought that > > either active (sending) or a passive > > (recieving) probing was a requirement > > for an active DC OSPF speaker. > > Not really. 1793 is based on the notion of "assumption of > reachability", which is quite important. With hello suppression > enabled, after a full adjacency has been established, we assume that > the neighbor is reachable unless we receive an explicit indication > proving this assumption wrong. 1793 mentions one possible > indication--failure of the dialer to reach the guy. The document in > question introduces another--failure of the reliable flooding > mechanism to deliver an LSA. > > > I classify DC nbrs that don't meet this > > criteria for 1 hr, .... > > (Sorry, Intellectural property and is > > extraneous information) :-) > > It is definitely possible to have implementation-specific mechanisms > that decide when to bring a DC neighbor down. Note though that your > approach may result in loss of connectivity when a multi-point dialer > (one with more than one next-hop-to-phone-num mappings) doesn't even > try to dial some remote locations due to the lack of application > traffic in that direction... > > > Lets work with your 2nd paragraph. > > > Lets assume that the nbr can not be probed for > > over 1 hr and does not initiate a probe for > > over 1 hr. And that all its interfaces are > > DC based. > > We should be clear whether you mean "a nbr is not probed for over 1hr > because of the ProbeInterval" or "a nbr does not reply to probes for > over 1hr". The latter is an indication of unreachability and should > be caught by ProbeRetxLimit. The former is completely normal. > > > Is it still a valid OSPF active speaker if > > the only entries in its link state tables > > are its own? Remember everything else is > > flushed. > > If all links are DC, then all received LSAs will be DNA. Provided that > the adjacencies are not brought down, I don't see how all other LSAs > could be assumed to be flushed. By stating that all links are DC, I am trying to imply that all the routers on those links are DC routers originating DNA LSAs. If data links at one router is down for 1 hr or more, then reachability is not met for that 1hr time frame and via rfc1793 the DNA LSAs are then flushed at the ONE router that had its links down! The other DC routers will only flush the one DC router that has not been reachable for that 1 hr timeframe. > > However, regardless of the above point, it is absolutely normal for a > DC-connected router to not hear from its neighbor for more than one > hour, because there may be no application traffic going in its > direction and no topology changes that should be communicated to it. > So, yes, it is still a valid OSPF speaker. Keep the presumption of > reachability in mind. So, I would expect DNA LSAs to be flushed according to rfc1793 2.3 - 2! The presumption of reachability is that we can establish an open link before we send app data and that the router will exist on the other side. The adj exists forever.. > > > Why would OSPF want to allow this level of > > depricated implimentation? Doesn't it > > just consume nbr slots forever? > > See above about proving wrong assumption of reachability. > > > Why wouldn't you want to explicitly state > > about stale LSAs? How many non OSPF > > developers realize the consequences of > > 1 hr plus probes. > > It is not clear to me what you are proposing to state > about stale LSAs. > That stale LSAs are the result of a down link of 1 hr or more after origination. See above for more. > Regards > > Alex From owner-ospf@PEACH.EASE.LSOFT.COM Fri May 30 18:24:58 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01684 for ; Fri, 30 May 2003 18:24:57 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.009EF09D@cherry.ease.lsoft.com>; Fri, 30 May 2003 18:24:56 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 44193246 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 30 May 2003 18:19:47 -0400 Received: from 147.28.0.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 30 May 2003 18:19:47 -0400 Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 19LsDy-000HXj-00; Fri, 30 May 2003 22:19:46 +0000 X-Mailer: The Bat! (v1.62i) Personal X-Priority: 3 (Normal) References: <3ED509DA.C7720CAB@earthlink.net> <3ED516E3.35CF71BB@earthlink.net> <3ED7062A.B5B24249@earthlink.net> <3ED77888.2040301@redback.com> <3ED7934E.68E18ECD@earthlink.net> <119577854701.20030530121234@psg.com> <3ED7CC53.13ECD3C2@earthlink.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <156589030851.20030530151850@psg.com> Date: Fri, 30 May 2003 15:18:50 -0700 Reply-To: Mailing List Sender: Mailing List From: Alex Zinin Subject: Re: FW: Last Call: Detecting Inactive Neighbors over OSPF Demand Comments: cc: Erblichs To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <3ED7CC53.13ECD3C2@earthlink.net> Precedence: list Content-Transfer-Encoding: 7bit Mitchell- Let me try one more time. Starting with inlines, a bit out of order though: [...] > If data links at one router is down for 1 hr or more, then > reachability is not met for that 1hr time frame and via rfc1793 the > DNA LSAs are then flushed at the ONE router that had its links > down! This seems to be the source of the confusion. The fact that the data link to a guy has not gone up for 1h or more does NOT mean that the reachability condition has not been met. The 1hr originator reachability condition is checked through SPF, and 1793 is very explicit about it. This means that as long as you have NOT received an evidence of unreachability of your neighbor, the adjacency will stay up, and you (as well as other routers) will consider the guy reachable even if the data link has never gone up. [...] >> Correct, and this is how it is supposed to work. > If it is NOT, 1 hr REACHABLE, then DC DNA LSAs are > flushed via rfc1793 2.3 - 2, in 1 hr time frame. > This is specified specifly for DC router DNA LSAs, > but will also occur for non-DNA LSAs, due to the > fact of "reachability failure"., but will not > allow updates to refresh non-DNA LSAs on > the DC router, because.. > "..., OSPF Hellos and the refresh of OSPF routing > information are suppressed on demand circuits, allowing the > underlying data-link connections to be closed when not carrying > application traffic." Refreshes never come on the DC links, and don't have to. If you have non-DNA LSAs then you have non-DC links and the refreshes will come on them, not on the DC links. > thus, Do you really think a OSPF router that only has > its own LSAs can be a valid OSPF router? Yes, see my previous message > Justify to me that this router is doing any good after > the link has been down for 1hr or more? ditto >> >> However, regardless of the above point, it is absolutely normal for a >> DC-connected router to not hear from its neighbor for more than one >> hour, because there may be no application traffic going in its >> direction and no topology changes that should be communicated to it. >> So, yes, it is still a valid OSPF speaker. Keep the presumption of >> reachability in mind. > So, I would expect DNA LSAs to be flushed according to > rfc1793 2.3 - 2! Nope. I think you are confused with what "Reachability" means. See my first comment above. > The presumption of reachability is that we can establish > an open link before we send app data and that the router > will exist on the other side. The adj exists forever.. >> It is not clear to me what you are proposing to state >> about stale LSAs. >> > That stale LSAs are the result of a down link of 1 > hr or more after origination. See above for more. This is not true, as the originator is still reachable because the adjacency is still up. > And all of this is to suggest that a DC router in my opinion > SHOULD send or recieve sucessful probes to/from each DC nbr > within each monotomically hr. > > And that a successful probe will determine that a > data-link is not closed and data will have a decent > probably of being accepted. This does imply that > the probe opens the connection, just that the > connection is open at the time of the probe. I don't think we should put this in the spec. I also believe this will cause problems with multi-point dialers (see last paragraph in Section 2 of the document.) On the other hand, if you believe this is useful, you can definitely add this to your implementation and still successfully interoperate. Alex From owner-ospf@PEACH.EASE.LSOFT.COM Sat May 31 03:13:05 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25920 for ; Sat, 31 May 2003 03:13:04 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.009EFF5D@cherry.ease.lsoft.com>; Sat, 31 May 2003 3:13:03 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 44229100 for OSPF@PEACH.EASE.LSOFT.COM; Sat, 31 May 2003 03:13:01 -0400 Received: from 203.197.140.35 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sat, 31 May 2003 03:13:00 -0400 Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Sat, 31 May 2003 12:52:39 +0530 Received: from vivekd (vivekd.future.futsoft.com [10.20.6.77]) by kailash.future.futsoft.com (8.12.2/8.12.2) with SMTP id h4V7AT7h005123 for ; Sat, 31 May 2003 12:40:29 +0530 MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-ID: <000001c32744$141b51e0$4d06140a@future.futsoft.com> Date: Sat, 31 May 2003 12:43:02 +0530 Reply-To: Mailing List Sender: Mailing List From: Vivek Dubey Subject: Re: FW: Last Call: Detecting Inactive Neighbors over OSPF Demand To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit Roy, Adjacency will be restored up again but won't the purpose of "graceful restart" somewhat defeated then (NBR is needlessly considered dead - though it is trying graceful restart). Won't it be better, if it is explicitly mentioned: 1)Generally graceful restart techniques should finish well before the probe retries (configurable) are finished(as you said in reply). OR 2)If the router has received grace LSA from other end point.... delay "Nbr probing" till "graceful restart" process completes. thanks, vivek -----Original Message----- From: Mailing List [mailto:OSPF@peach.ease.lsoft.com]On Behalf Of Abhay Roy Sent: Saturday, 31 May 2003 1:17 AM To: OSPF@peach.ease.lsoft.com Subject: Re: FW: Last Call: Detecting Inactive Neighbors over OSPF Demand Vivek, Generally graceful restart techniques should finish well before the probe retries (configurable) are finished. If it does not, then yes, we will consider the neighbor dead. But it's not a big problem, because the adjacency will come right back up. I guess implementations could choose to factor in the grace period to 'delay' probes. Regards, -Roy- On 05/30/03+0530 at 8:48pm, Vivek Dubey writes: > Roy, > Suppose the time "Nbr probing" starts, the Ospf at the > other end is undergoing "graceful restart"...(grace period > 1800 sec)..... > while probing fails at this end..... > should we consdier NBR dead or there is some "safeguard" > in RFC 1793 - graceful restart - and Nbr probing draft, for such scenario. > > > > thanks, > vivek > > > > -----Original Message----- > From: Mailing List [mailto:OSPF@peach.ease.lsoft.com]On Behalf Of Abhay > Roy > Sent: Friday, 30 May 2003 2:06 PM > To: OSPF@peach.ease.lsoft.com > Subject: Re: FW: Last Call: Detecting Inactive Neighbors over OSPF > Demand > > > Mitchell, > > The important point to note here is that: If the originator is > 'reachable', DoNotAge LSA's can stay forever. > > Regards, > -Roy- > > On 05/30/03-0700 at 12:20am, Erblichs writes: > > > Lets cover two stones with one throw.. > > > > Lets try part of this again.. > > > > In the 1793 RFC which deals with demand circuits, > > there is a 2.3 - 2) section that mentions MaxAge > > seconds, aka 3600 seconds or 1 hr. > > > > To ensure that these LSAs are eventually > > flushed from the routing domain, and that the size of the link > > state database doesn't grow without bound, routers are required to > > flush a DoNotAge LSA if BOTH of the following conditions are met: > > > > (2) The originator of the LSA has been unreachable (according to > > the routing calculations specified by Section 16 of [1]) for > > at least MaxAge seconds. > > > > If probe exceeds 1 hr then LSAs are most likely > > dropped and LSAs need to be originated. Thus, tell > > me why you would want to allow LSAs to be forced > > to be re-originated in favor of a longer probe. > > > > I also think you may get a dead nbr, but that is > > a different discussion point.. > > > > Mitchell Erblich > > Sr Software Engineer > > --------------------- > > > > > > Mitchell, > > > > In case of 'always up' DC links, it does turn out to be periodic > > probing. But in case of 'on demand' DC links, (if there is no data > > traffic) it's of no use to bring up the link just to send probes. > > So it makes sense to piggy back this event on the link coming up > > event, and keep doing it periodically till the time line remains > > up (due to data traffic). > > > > Regards, > > -Roy- > > > > > > > > Abhay Roy wrote: > > > > > > Mitchell, > > > > > > Why it MUST not exceed 1hr? Today it's infinity, so in theory any > > > interval (including absurdly high ones) should be allowed. > > > > > > Regards, > > > -Roy- > > > > > > On 05/28/03-0700 at 1:06pm, Erblichs writes: > > > > > > > Sorry group, > > > > > > > > I forgot.. > > > > > > > > E) If ..ProbeInterval is kept, its max value MUST not exceed > > > > 1 hr.. > > > > > > > > I think this follows that if we haven't heard from our > > > > nbr in 1 hr "he" is considered dead. > > > > > > > > Mitchell Erblich > > > > ------------------- > > > > *************************************************************************** > This message is proprietary to Future Software Limited (FSL) > and is intended solely for the use of the individual to whom it > is addressed. It may contain privileged or confidential information > and should not be circulated or used for any purpose other than for > what it is intended. > > If you have received this message in error, please notify the > originator immediately. If you are not the intended recipient, > you are notified that you are strictly prohibited from using, > copying, altering, or disclosing the contents of this message. > FSL accepts no responsibility for loss or damage arising from > the use of the information transmitted by this email including > damage from virus. > *************************************************************************** > *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. ***************************************************************************