From owner-ospf*ospf-archive**LISTS*-IETF*-ORG@PEACH.EASE.LSOFT.COM Mon Jun 6 10:10:53 2005 Received: from almond.ease.lsoft.com (almond.ease.lsoft.com [209.119.0.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03434 for ; Mon, 6 Jun 2005 10:10:53 -0400 (EDT) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by almond.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <5.008C6BC9@almond.ease.lsoft.com>; Mon, 6 Jun 2005 10:10:54 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 74317752 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 6 Jun 2005 10:10:52 -0400 Received: from 216.148.248.31 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 6 Jun 2005 10:00:52 -0400 Received: by SYSAMAWIL1BE with Internet Mail Service (5.5.2657.72) id ; Mon, 6 Jun 2005 09:59:22 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <82EA2C90A03BD6118B100008C7B1626B05DEF5D0@SYSAMAWIL1AE> Date: Mon, 6 Jun 2005 10:02:11 -0400 Reply-To: Mailing List Sender: Mailing List From: "Welsh, Robert" Subject: Re: Working Group Last Call for "Traffic Engineering Extensions t o OSPF version 3" To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list What level do we usually use for a PHd student? -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of Adrian Farrel Sent: Monday, May 23, 2005 6:33 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: Working Group Last Call for "Traffic Engineering Extensions to OSPF version 3" Hi, Two comments... 1. Would it be possible to clarify the behavior if the scope is set to some value other than 01? Is it a requirement that the scope be ignored in that case, that TE information be allowed to be flooded out of the area, or that the LSA is rejected? Given the setting of the U-bit, this may be hard to control properly and I suspect the best you can do is say MUST be transmitted as 01 and SHOULD only be flooded within the area. 2. Section 4 - Router IPv6 Address TLV "The Router IPv6 Address TLV has type 3, length 16, and a value containing a 16 octet local IPv6 address. It MUST appear in exactly one Traffic Engineering LSA originated by an OSPFv3 router supporting the TE extensions." I am confused by 'MUST appear in exactly one'. Can a router advertise multiple Router addresses? (Hint, please talk to the CCAMP ASON Routing design team for a very good reason why the answer is "yes".) Can a TE LSA contain "orphaned" TLVs? I.e. can we have a continuation TE LSA that does not carry a Router Address TLV? Given that a router has (probably) more than one "stable IPv6 address that is always reachable if there is connectivity to the OSPFv3 router" must all of these be advertised in Router Address TLVs? The text needs to cover all of these questions. Cheers, Adrian From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jun 8 19:52:23 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04621 for ; Wed, 8 Jun 2005 19:52:23 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.01075EE6@cherry.ease.lsoft.com>; Wed, 8 Jun 2005 19:52:20 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 74656065 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 8 Jun 2005 19:52:02 -0400 Received: from 171.71.176.71 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 8 Jun 2005 19:52:02 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 08 Jun 2005 16:52:02 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j58NpdmE012432; Wed, 8 Jun 2005 16:51:56 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 8 Jun 2005 16:51:57 -0700 Received: from [192.168.0.2] ([10.21.89.55]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 8 Jun 2005 16:51:56 -0700 User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <000701c56c04$eddbc840$bc04120a@china.huawei.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 08 Jun 2005 23:51:56.0925 (UTC) FILETIME=[0DE15AD0:01C56C85] Message-ID: <42A7849C.4010406@cisco.com> Date: Wed, 8 Jun 2005 16:51:56 -0700 Reply-To: Mailing List Sender: Mailing List From: Padma Pillay-Esnault Subject: Re: regarding ospf las flushing ..... Comments: To: anupkumart@huawei.com To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <000701c56c04$eddbc840$bc04120a@china.huawei.com> Precedence: list Content-Transfer-Encoding: 8bit Anup This was already done in a major implementation. I think it was a good idea. You have to be careful though as this might break some implementation who access the body of the lsa on flushing ( though I don't see why they would do that). I'm for it and can collaborate. This can initiate a discussion on the list. Padma anup wrote: > Hello Padma, > > As per RFC 2328, we send the lsa (header + body) to the peer though > the lsa is maxaged. > > Considering that the peer would not examine the lsa body if the lsa is > maxaged, *if we could send only the maxaged lsa’s header*, it would > reduce a lot of traffic as well as the protocol memory consumption > during flushing. > > If you agree with this idea, I would like to prepare a small draft on > this. > > Regards, > > Anup > From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jun 8 19:58:34 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04990 for ; Wed, 8 Jun 2005 19:58:34 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.01075DD2@cherry.ease.lsoft.com>; Wed, 8 Jun 2005 19:58:34 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 74656351 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 8 Jun 2005 19:58:21 -0400 Received: from 143.209.238.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 8 Jun 2005 19:58:21 -0400 Received: from mvrelay.mv.usa.alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id j58Nw1mg013322; Wed, 8 Jun 2005 18:58:06 -0500 (CDT) Received: from dgoodspeedpc (localhost [127.0.0.1]) by mvrelay.mv.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id j58NvvYm018306; Wed, 8 Jun 2005 16:57:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Thread-index: AcVshRR7AkVdwxTjTh+qv6vGjN5dyQAAHxaA Message-ID: <200506082357.j58NvvYm018306@mvrelay.mv.usa.alcatel.com> Date: Wed, 8 Jun 2005 16:58:08 -0700 Reply-To: Mailing List Sender: Mailing List From: Don Goodspeed Organization: Alcatel Subject: Re: regarding ospf las flushing ..... Comments: To: Padma Pillay-Esnault , anupkumart@huawei.com To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <42A7849C.4010406@cisco.com> Precedence: list Content-Transfer-Encoding: 7bit Padma, How does one address the issues of summary and external LSAs where the LSID "may" change depending upon Appendix E of RFC2328. In those cases, isn't including the subnet mask needed? Otherwise, an incorrect LSA could be flushed. -don -----Original Message----- From: owner-ospf@PEACH.EASE.LSOFT.COM [mailto:owner-ospf@PEACH.EASE.LSOFT.COM] On Behalf Of Padma Pillay-Esnault Sent: Wednesday, June 08, 2005 4:52 PM To: anupkumart@huawei.com Cc: OSPF@PEACH.EASE.LSOFT.COM; Padma Pillay-Esnault Subject: Re: regarding ospf las flushing ..... Anup This was already done in a major implementation. I think it was a good idea. You have to be careful though as this might break some implementation who access the body of the lsa on flushing ( though I don't see why they would do that). I'm for it and can collaborate. This can initiate a discussion on the list. Padma anup wrote: > Hello Padma, > > As per RFC 2328, we send the lsa (header + body) to the peer though > the lsa is maxaged. > > Considering that the peer would not examine the lsa body if the lsa is > maxaged, *if we could send only the maxaged lsa's header*, it would > reduce a lot of traffic as well as the protocol memory consumption > during flushing. > > If you agree with this idea, I would like to prepare a small draft on > this. > > Regards, > > Anup > From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jun 8 20:23:46 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06638 for ; Wed, 8 Jun 2005 20:23:46 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.01075F87@cherry.ease.lsoft.com>; Wed, 8 Jun 2005 20:23:46 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 74657765 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 8 Jun 2005 20:23:37 -0400 Received: from 207.17.137.57 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 8 Jun 2005 20:23:37 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id j590Nb987749 for ; Wed, 8 Jun 2005 17:23:37 -0700 (PDT) (envelope-from qv@juniper.net) Received: from fuinar.juniper.net (fuinar.juniper.net [172.17.12.75]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j590NSe34712 for ; Wed, 8 Jun 2005 17:23:32 -0700 (PDT) (envelope-from qv@juniper.net) Received: from fuinar.juniper.net (localhost [127.0.0.1]) by fuinar.juniper.net (8.12.8p1/8.12.3) with ESMTP id j590NS1i032909 for ; Wed, 8 Jun 2005 17:23:28 -0700 (PDT) (envelope-from qv@fuinar.juniper.net) Received: (from qv@localhost) by fuinar.juniper.net (8.12.8p1/8.12.3/Submit) id j590NSpf032906; Wed, 8 Jun 2005 17:23:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable References: <000701c56c04$eddbc840$bc04120a@china.huawei.com> <42A7849C.4010406@cisco.com> X-Mailer: VM 7.14 under 21.4 (patch 12) "Portable Code" XEmacs Lucid Message-ID: <17063.35839.774123.505141@fuinar.juniper.net> Date: Wed, 8 Jun 2005 17:23:27 -0700 Reply-To: Mailing List Sender: Mailing List From: Quaizar Vohra Subject: Re: regarding ospf las flushing ..... To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <42A7849C.4010406@cisco.com> Precedence: list Content-Transfer-Encoding: quoted-printable But that major implementation had to revert to sending the entire LSA (header + body) because another major implementation did not like it :). Have gone thru enought pain on this subject and would prefer not having to do yet another revision. As far as efficiency and memory is concerned, I wouldn't worry too much about it for this particular case. Quaizar > Anup >=20 > This was already done in a major implementation. I think it was a go= od idea. >=20 > You have to be careful though as this might break some implementatio= n who > access the body of the lsa on flushing ( though I don't see why they= =20 > would do that). >=20 > I'm for it and can collaborate. This can initiate a discussion on th= e list. >=20 > Padma >=20 > anup wrote: >=20 > > Hello Padma, > > > > As per RFC 2328, we send the lsa (header + body) to the peer thoug= h=20 > > the lsa is maxaged. > > > > Considering that the peer would not examine the lsa body if the ls= a is=20 > > maxaged, *if we could send only the maxaged lsa=92s header*, it wo= uld=20 > > reduce a lot of traffic as well as the protocol memory consumption= =20 > > during flushing. > > > > If you agree with this idea, I would like to prepare a small draft= on=20 > > this. > > > > Regards, > > > > Anup > > From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jun 8 20:30:15 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07067 for ; Wed, 8 Jun 2005 20:30:15 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.01075FD0@cherry.ease.lsoft.com>; Wed, 8 Jun 2005 20:30:15 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 74658072 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 8 Jun 2005 20:30:14 -0400 Received: from 207.17.137.57 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 8 Jun 2005 20:30:14 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id j590UD987843 for ; Wed, 8 Jun 2005 17:30:13 -0700 (PDT) (envelope-from dkatz@juniper.net) Received: from [172.16.12.13] (nimbus-sc.juniper.net [172.16.12.13]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j590U8e36022 for ; Wed, 8 Jun 2005 17:30:08 -0700 (PDT) (envelope-from dkatz@juniper.net) Mime-Version: 1.0 (Apple Message framework v622) References: <200506082357.j58NvvYm018306@mvrelay.mv.usa.alcatel.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.622) Message-ID: <791dafdc8f35a6f8041879fb458aec86@juniper.net> Date: Wed, 8 Jun 2005 17:30:06 -0700 Reply-To: Mailing List Sender: Mailing List From: Dave Katz Subject: Re: regarding ospf las flushing ..... To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <200506082357.j58NvvYm018306@mvrelay.mv.usa.alcatel.com> Precedence: list Content-Transfer-Encoding: 7bit The tuple of originating router, LSA ID, and LSA type *always* uniquely and completely identifies an LSA, by definition. There can never be any ambiguity about which LSA is being flushed, even when only the header is sent. The only way this could even conceptually be an issue is if an implementation thought it could send two different external routes with the same LSA ID but different masks, but this is not allowed (I seem to recall that there was evidence that some misguided implementation attempted such a thing recently.) I wrote the Juniper implementation this way back in '97 and things worked swimmingly until a broken implementation came along that tried to access the contents of the LSA before noticing that it was being flushed, and did something bad (like crashed.) I don't recall offhand how this was resolved, though I'm sure I resisted changing our implementation. --Dave On Jun 8, 2005, at 4:58 PM, Don Goodspeed wrote: > Padma, > > How does one address the issues of summary and external > LSAs where the LSID "may" change depending upon Appendix > E of RFC2328. In those cases, isn't including the subnet > mask needed? Otherwise, an incorrect LSA could be flushed. > > -don > > -----Original Message----- > From: owner-ospf@PEACH.EASE.LSOFT.COM > [mailto:owner-ospf@PEACH.EASE.LSOFT.COM] On Behalf Of Padma > Pillay-Esnault > Sent: Wednesday, June 08, 2005 4:52 PM > To: anupkumart@huawei.com > Cc: OSPF@PEACH.EASE.LSOFT.COM; Padma Pillay-Esnault > Subject: Re: regarding ospf las flushing ..... > > Anup > > This was already done in a major implementation. I think it was a good > idea. > > You have to be careful though as this might break some implementation > who > access the body of the lsa on flushing ( though I don't see why they > would do that). > > I'm for it and can collaborate. This can initiate a discussion on the > list. > > Padma > > anup wrote: > >> Hello Padma, >> >> As per RFC 2328, we send the lsa (header + body) to the peer though >> the lsa is maxaged. >> >> Considering that the peer would not examine the lsa body if the lsa is >> maxaged, *if we could send only the maxaged lsa's header*, it would >> reduce a lot of traffic as well as the protocol memory consumption >> during flushing. >> >> If you agree with this idea, I would like to prepare a small draft on >> this. >> >> Regards, >> >> Anup >> > From owner-ospf@PEACH.EASE.LSOFT.COM Thu Jun 9 01:15:01 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00916 for ; Thu, 9 Jun 2005 01:15:00 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.010763F0@cherry.ease.lsoft.com>; Thu, 9 Jun 2005 1:14:59 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 74673276 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 9 Jun 2005 01:14:57 -0400 Received: from 207.17.137.57 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 9 Jun 2005 01:14:57 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id j595Eu989428 for ; Wed, 8 Jun 2005 22:14:56 -0700 (PDT) (envelope-from dkatz@juniper.net) Received: from [172.16.12.13] (nimbus-sc.juniper.net [172.16.12.13]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j595Epe83607 for ; Wed, 8 Jun 2005 22:14:51 -0700 (PDT) (envelope-from dkatz@juniper.net) Mime-Version: 1.0 (Apple Message framework v622) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed X-Mailer: Apple Mail (2.622) Message-ID: Date: Wed, 8 Jun 2005 22:14:48 -0700 Reply-To: Mailing List Sender: Mailing List From: Dave Katz Subject: Re: regarding ospf las flushing ..... To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit On Jun 8, 2005, at 5:23 PM, Quaizar Vohra wrote: > But that major implementation had to revert to sending the entire > LSA (header + body) because another major implementation did not > like it :). > > Have gone thru enought pain on this subject and would prefer not > having to do yet another revision. As far as efficiency and memory > is concerned, I wouldn't worry too much about it for this particular > case. I guess this explains how it was resolved. Obviously my resistance was futile. ;-) --Dave From owner-ospf@PEACH.EASE.LSOFT.COM Thu Jun 9 06:07:47 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09123 for ; Thu, 9 Jun 2005 06:07:46 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.0107659C@cherry.ease.lsoft.com>; Thu, 9 Jun 2005 6:07:43 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 74689353 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 9 Jun 2005 06:07:40 -0400 Received: from 144.254.224.140 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 9 Jun 2005 06:01:10 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 09 Jun 2005 12:01:07 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j59A147F002087 for ; Thu, 9 Jun 2005 12:01:04 +0200 (MEST) Received: from mshand-w2k02.cisco.com (dhcp-rea-gp250-64-103-64-198.cisco.com [64.103.64.198]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id LAA20560; Thu, 9 Jun 2005 11:01:03 +0100 (BST) X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 References: <000701c56c04$eddbc840$bc04120a@china.huawei.com> <000701c56c04$eddbc840$bc04120a@china.huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <4.3.2.7.2.20050609105725.02826960@jaws.cisco.com> Date: Thu, 9 Jun 2005 11:01:02 +0100 Reply-To: Mailing List Sender: Mailing List From: mike shand Subject: Re: regarding ospf las flushing ..... To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <42A7849C.4010406@cisco.com> Precedence: list Of course a certain other Link State Protocol has always specified that this is what you should do i.e. send only the header, (not that all implementations follow the spec in this regard:-) Mike At 00:51 09/06/2005, Padma Pillay-Esnault wrote: >Anup > >This was already done in a major implementation. I think it was a good idea. > >You have to be careful though as this might break some implementation who >access the body of the lsa on flushing ( though I don't see why they would >do that). > >I'm for it and can collaborate. This can initiate a discussion on the list. > >Padma > >anup wrote: > >>Hello Padma, >> >>As per RFC 2328, we send the lsa (header + body) to the peer though the >>lsa is maxaged. >> >>Considering that the peer would not examine the lsa body if the lsa is >>maxaged, *if we could send only the maxaged lsa's header*, it would >>reduce a lot of traffic as well as the protocol memory consumption during >>flushing. >> >>If you agree with this idea, I would like to prepare a small draft on this. >> >>Regards, >> >>Anup From owner-ospf@PEACH.EASE.LSOFT.COM Thu Jun 9 12:59:22 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21689 for ; Thu, 9 Jun 2005 12:59:22 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.01076C0A@cherry.ease.lsoft.com>; Thu, 9 Jun 2005 12:59:23 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 74764811 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 9 Jun 2005 12:59:22 -0400 Received: from 171.71.176.70 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 9 Jun 2005 12:59:22 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 09 Jun 2005 09:59:21 -0700 X-IronPort-AV: i="3.93,186,1115017200"; d="scan'208"; a="642369169:sNHT42926060" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j59GxJlq004945 for ; Thu, 9 Jun 2005 09:59:19 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 9 Jun 2005 09:58:43 -0700 Received: from [128.107.178.151] ([128.107.178.151]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 9 Jun 2005 09:58:42 -0700 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <000701c56c04$eddbc840$bc04120a@china.huawei.com> <42A7849C.4010406@cisco.com> <17063.35839.774123.505141@fuinar.juniper.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 09 Jun 2005 16:58:42.0778 (UTC) FILETIME=[7DD483A0:01C56D14] Message-ID: <42A87543.8030807@cisco.com> Date: Thu, 9 Jun 2005 12:58:43 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: regarding ospf las flushing ..... To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <17063.35839.774123.505141@fuinar.juniper.net> Precedence: list Content-Transfer-Encoding: 8bit Quaizar Vohra wrote: >But that major implementation had to revert to sending the entire >LSA (header + body) because another major implementation did not >like it :). > >Have gone thru enought pain on this subject and would prefer not >having to do yet another revision. As far as efficiency and memory >is concerned, I wouldn't worry too much about it for this particular >case. > > I guess I'd have to agree with this. There would have to be some WG momentum and we'd need to address the backward compatibility issues given that we know there are deployed implementations that have problems with the header-only LSA flush. BTW, I previously worked on a less-deployed (avoiding the adjective "minor") implementation that accepted header-only LSA flushes but would not send them :^) Thanks, Acee >Quaizar > > > > Anup > > > > This was already done in a major implementation. I think it was a good idea. > > > > You have to be careful though as this might break some implementation who > > access the body of the lsa on flushing ( though I don't see why they > > would do that). > > > > I'm for it and can collaborate. This can initiate a discussion on the list. > > > > Padma > > > > anup wrote: > > > > > Hello Padma, > > > > > > As per RFC 2328, we send the lsa (header + body) to the peer though > > > the lsa is maxaged. > > > > > > Considering that the peer would not examine the lsa body if the lsa is > > > maxaged, *if we could send only the maxaged lsa’s header*, it would > > > reduce a lot of traffic as well as the protocol memory consumption > > > during flushing. > > > > > > If you agree with this idea, I would like to prepare a small draft on > > > this. > > > > > > Regards, > > > > > > Anup > > > > > > From owner-ospf@PEACH.EASE.LSOFT.COM Thu Jun 9 15:02:25 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04483 for ; Thu, 9 Jun 2005 15:02:25 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.01076D54@cherry.ease.lsoft.com>; Thu, 9 Jun 2005 15:02:24 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 74774580 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 9 Jun 2005 15:02:23 -0400 Received: from 207.17.137.64 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 9 Jun 2005 15:02:23 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id j59J2MBm029423 for ; Thu, 9 Jun 2005 12:02:22 -0700 (PDT) (envelope-from dkatz@juniper.net) Received: from [172.16.12.13] (nimbus-sc.juniper.net [172.16.12.13]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j59J2Me24244 for ; Thu, 9 Jun 2005 12:02:22 -0700 (PDT) (envelope-from dkatz@juniper.net) Mime-Version: 1.0 (Apple Message framework v622) References: <000701c56c04$eddbc840$bc04120a@china.huawei.com> <000701c56c04$eddbc840$bc04120a@china.huawei.com> <4.3.2.7.2.20050609105725.02826960@jaws.cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.622) Message-ID: Date: Thu, 9 Jun 2005 12:02:18 -0700 Reply-To: Mailing List Sender: Mailing List From: Dave Katz Subject: Re: regarding ospf las flushing ..... To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <4.3.2.7.2.20050609105725.02826960@jaws.cisco.com> Precedence: list Content-Transfer-Encoding: 7bit On Jun 9, 2005, at 3:01 AM, mike shand wrote: > Of course a certain other Link State Protocol has always specified > that this is what you should do i.e. send only the header, (not that > all implementations follow the spec in this regard:-) Yes, and a certain implementor who had previously implemented the certain Link State Protocol took this to heart when implementing the uncertain Link State Protocol. ;-) --Dave From owner-ospf@PEACH.EASE.LSOFT.COM Fri Jun 10 14:51:12 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19550 for ; Fri, 10 Jun 2005 14:51:11 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.010780DC@cherry.ease.lsoft.com>; Fri, 10 Jun 2005 14:51:08 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 74906871 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 10 Jun 2005 14:51:06 -0400 Received: from 171.68.10.87 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 10 Jun 2005 14:51:06 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by sj-iport-5.cisco.com with ESMTP; 10 Jun 2005 11:51:05 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j5AIp1NA024481; Fri, 10 Jun 2005 14:51:02 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 10 Jun 2005 14:50:32 -0400 Received: from [10.82.216.98] ([10.82.216.98]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 10 Jun 2005 14:50:32 -0400 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <200505231945.PAA03257@ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Jun 2005 18:50:32.0388 (UTC) FILETIME=[477B8040:01C56DED] Message-ID: <42A9E0F9.1020902@cisco.com> Date: Fri, 10 Jun 2005 14:50:33 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: I-D ACTION:draft-ietf-ospf-cap-07.txt Comments: To: Adrian Farrel To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <200505231945.PAA03257@ietf.org> Precedence: list Content-Transfer-Encoding: 7bit This version of the draft attempts to satisfy Adrian Farrel's comments as well as including an LSA definition for OSPFv3. At this point, I'd like to re-last call it. All comments should be sent to this list by 12 AM (EDT), 06/24/2005. A URL for this Internet-Draft is: A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-cap-07.txt There is (at least) one typo in the IANA considerations that I will fix prior to queueing the document for IESG review. Thanks, Acee Internet-Drafts@IETF.ORG wrote: >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF. > > Title : Extensions to OSPF for Advertising Optional Router > Capabilities > Author(s) : A. Lindem, et al. > Filename : draft-ietf-ospf-cap-07.txt > Pages : 14 > Date : 2005-5-23 > >It is useful for routers in an OSPFv2 or OSPFv3 routing domain to > know the capabilities of their neighbors and other routers in the > routing domain. This draft proposes extensions to OSPFv2 and OSPFv3 > for advertising optional router capabilities. A new Router > Information (RI) LSA is proposed for this purpose. In OSPFv2, the RI > LSA will be implemented with a new opaque LSA type ID. In OSPFv3, > the RI LSA will be implemented with a new LSA type function code. In > both protocols, the RI LSA can be advertised at any of the defined > flooding scopes (link, area, or AS). > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-ospf-cap-07.txt > >To remove yourself from the I-D Announcement list, send a message to >i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. >You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >to change your subscription settings. > > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-ospf-cap-07.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-ietf-ospf-cap-07.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >------------------------------------------------------------------------- >CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY >------------------------------------------------------------------------- >In order to maintain computing infrastructure integrity, Cisco Systems >Enterprise Messaging Services and InfoSec teams have set a mail policy >disallowing executable attachments in email. > >This message contained an executable attachment type that is prohibited >by this policy. The attachment has been removed from this message and >copied to quarantine by our systems. It will be held in quarantine for >seven days in the event that the content needs to be retrieved. > >Please be aware many viruses attempt to look like legitimate email or >notifications from anti-virus systems. We will clearly mark a seperation >between our notifications and the original email as follows: > > "CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY" > >For further reference information about viruses and email antivirus >efforts within Cisco, please visit: > >http://wwwin.cisco.com/it/ems/services/antiviral > >If your concern isn't addressed by the information in this notification >or the above web page, you may open a support request: > >http://wwwin.cisco.com/support/ > >Select "Messaging", "Email-Related", "Mail Routing" > >Please include in the text of your case the following information: > >* Full headers of the message. Documentation on displaying the full >headers is available at this URL: > >http://wwwin.cisco.com/support/library/faqs/solution002471.html > >* This unique quarantine identifier: j4NJtp53013712 > >If the matter is urgent, you may follow up by calling one of the below >referenced numbers. Please make every effort to provide the above >requested information via the support web tool prior to calling as it >will greatly aid the resolution of your issue. > >Americas: >1 408 526 8888 > >Asiapac >+61 2 8446 8888 > >EMEA >+31 20 485 4888 > >Japan >+81 3 5549 6888 > >US (Toll Free) >1| 800| 888| 8187| (ext.68888) > >Thank you for your cooperation, > >Enterprise Messaging Services >Cisco Systems, Inc > > From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jun 14 01:18:55 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18854 for ; Tue, 14 Jun 2005 01:18:54 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.0107BC78@cherry.ease.lsoft.com>; Tue, 14 Jun 2005 1:18:43 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 75300406 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 14 Jun 2005 01:18:42 -0400 Received: from 203.199.83.246 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 14 Jun 2005 01:08:42 -0400 Received: (qmail 5809 invoked by uid 510); 14 Jun 2005 05:10:14 -0000 Received: from unknown (203.126.136.223) by rediffmail.com via HTTP; 14 jun 2005 05:10:14 -0000 MIME-Version: 1.0 Content-type: multipart/alternative; boundary="Next_1118725814---0-203.199.83.246-5806" Message-ID: <20050614051014.5808.qmail@webmail35.rediffmail.com> Date: Tue, 14 Jun 2005 05:10:14 -0000 Reply-To: Mailing List Sender: Mailing List From: Vivek Dubey Subject: draft-ietf-ospf-ospfv3-update-03 To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This is a multipart mime message --Next_1118725814---0-203.199.83.246-5806 Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 1) Section 3.4.3 Originating LSAs=0A The state or interface ID of on= e of the router's interfaces=0A changes. The router may need to (re)o= riginate or flush its=0A Link-LSA and one or more router-LSAs and/or= =0A intra-area-prefix-LSAs.=0A=0A If router is DR, network LSA = should also be reoriginated=0A=0A2) Section 3.9 Multiple Interfaces to a si= ngle link=0A All of the multiple interfaces to the link will however appear= in the router-LSA=0A=0A Section 3.4.3.1 Router-LSAs=0A Nor are interfa= ces without any full adjacencies described.=0A=0A=0A As there will b= e no OSPF control traffic on standby interfaces, effectively no adjacency= =0Awill be present on the standby interface(s). Not clear why than the stan= dby interface be part of Router LSA ?=0A=0AThanks=0AVivek=0A=0A --Next_1118725814---0-203.199.83.246-5806 Content-type: text/html; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

=0A1)  Section 3.4.3  Originating LSAs
=0A    &nb= sp; The state or interface ID of one of the router's interfaces
=0A = ;     changes.  The router may need to (re)originate or flus= h its
=0A      Link-LSA and one or more router-LSAs and/o= r
=0A      intra-area-prefix-LSAs.
=0A
=0A<vivek= > If router is DR, network LSA should also be reoriginated
=0A
=0A= 2) Section 3.9 Multiple Interfaces to a single link
=0A    &nb= sp;All of the multiple interfaces to the link will however appear in the ro= uter-LSA
=0A
=0A    Section 3.4.3.1  Router-LSAs
= =0A     Nor are interfaces without any full adjacencies desc= ribed.
=0A
=0A
=0A<vivek> As there will be no OSPF control t= raffic on standby interfaces, effectively no adjacency
=0Awill be presen= t on the standby interface(s). Not clear why than the standby interface be = part of Router LSA ?
=0A
=0AThanks
=0AVivek
=0A
=0A=0A

= =0A

=0A=0A --Next_1118725814---0-203.199.83.246-5806-- From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jun 15 16:23:36 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25810 for ; Wed, 15 Jun 2005 16:23:36 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.0107F002@cherry.ease.lsoft.com>; Wed, 15 Jun 2005 16:23:32 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 75537441 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 15 Jun 2005 16:23:29 -0400 Received: from 132.151.6.50 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 15 Jun 2005 16:13:27 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1DieGN-0006xN-9h; Wed, 15 Jun 2005 16:13:27 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-ID: Date: Wed, 15 Jun 2005 16:13:27 -0400 Reply-To: Mailing List Sender: Mailing List From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ospf-ospfv3-graceful-restart-01.txt Comments: To: i-d-announce@ietf.org To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF. Title : OSPFv3 Graceful Restart Author(s) : P. Pillay-Esnault, A. Lindem Filename : draft-ietf-ospf-ospfv3-graceful-restart-01.txt Pages : 11 Date : 2005-6-15 This memo describes the OSPFv3 graceful restart. For OSPFv3, graceful restart is identical to OSPFv2 except for the differences described in this memo. These differences include the format of the grace Link State advertisements (LSA) and other considerations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-graceful-restart-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ospf-ospfv3-graceful-restart-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ospf-ospfv3-graceful-restart-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-6-15153946.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ospf-ospfv3-graceful-restart-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ospf-ospfv3-graceful-restart-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-6-15153946.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jun 15 21:51:18 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28189 for ; Wed, 15 Jun 2005 21:51:18 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.0107F365@cherry.ease.lsoft.com>; Wed, 15 Jun 2005 21:51:16 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 75538656 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 15 Jun 2005 21:51:14 -0400 Received: from 171.71.176.72 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 15 Jun 2005 21:51:14 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 15 Jun 2005 18:51:14 -0700 X-IronPort-AV: i="3.93,202,1115017200"; d="scan'208"; a="279322132:sNHT27582324" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j5G1p4lw004103 for ; Wed, 15 Jun 2005 18:51:11 -0700 (PDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 15 Jun 2005 21:50:51 -0400 Received: from [10.82.225.10] ([10.82.225.10]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 15 Jun 2005 21:50:50 -0400 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <20050614051014.5808.qmail@webmail35.rediffmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jun 2005 01:50:50.0960 (UTC) FILETIME=[D2FCF500:01C57215] Message-ID: <42B0DAFA.5080802@cisco.com> Date: Wed, 15 Jun 2005 21:50:50 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: draft-ietf-ospf-ospfv3-update-03 To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <20050614051014.5808.qmail@webmail35.rediffmail.com> Precedence: list Content-Transfer-Encoding: 7bit Hi Vivek, Vivek Dubey wrote: >1) Section 3.4.3 Originating LSAs > The state or interface ID of one of the router's interfaces > changes. The router may need to (re)originate or flush its > Link-LSA and one or more router-LSAs and/or > intra-area-prefix-LSAs. > > If router is DR, network LSA should also be reoriginated > > Agreed. I'll add this in the 05 revision. >2) Section 3.9 Multiple Interfaces to a single link > All of the multiple interfaces to the link will however appear in the router-LSA > > Section 3.4.3.1 Router-LSAs > Nor are interfaces without any full adjacencies described. > > > As there will be no OSPF control traffic on standby interfaces, effectively no adjacency >will be present on the standby interface(s). Not clear why than the standby interface be part of Router LSA ? > > The standby interfaces must be advertised so that other routers on the network can install equal cost multi-path routes. I guess 3.4.3.1 should reference the exception. Thanks for review, Acee >Thanks >Vivek > > > > From owner-ospf@PEACH.EASE.LSOFT.COM Thu Jun 16 09:50:20 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21589 for ; Thu, 16 Jun 2005 09:50:20 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.0107FE4B@cherry.ease.lsoft.com>; Thu, 16 Jun 2005 9:50:13 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 75613197 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 16 Jun 2005 09:48:05 -0400 Received: from 203.199.83.245 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 16 Jun 2005 09:48:03 -0400 Received: (qmail 18146 invoked by uid 510); 16 Jun 2005 13:49:36 -0000 Received: from unknown (203.126.136.223) by rediffmail.com via HTTP; 16 jun 2005 13:49:36 -0000 MIME-Version: 1.0 Content-type: multipart/alternative; boundary="Next_1118929776---0-203.199.83.245-18142" Message-ID: <20050616134936.18145.qmail@mailweb33.rediffmail.com> Date: Thu, 16 Jun 2005 13:49:36 -0000 Reply-To: Mailing List Sender: Mailing List From: Vivek Dubey Subject: Re: draft-ietf-ospf-ospfv3-update-03 To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This is a multipart mime message --Next_1118929776---0-203.199.83.245-18142 Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Acee,=0AIn continuation:=0A=0A2) Section 3.9 Multiple Interfaces to a si= ngle link=0AAll of the multiple interfaces to the link will however appear = in the router-LSA=0A=0A Section 3.4.3.1 Router-LSAs=0ANor are interfaces= without any full adjacencies described.=0A=0A Agreed it would be mo= re clear if exception in Section 3.4.3.1 is mentioned. Further, issue is, h= ow should they be represented in the Router-LSA. I think repeating each NBR= (of active interface on link) in standy interface description is redundant,= though it preserves the current Router-LSA format. =0A=0A=0AThanks=0AVivek= =0A=0A=0A --Next_1118929776---0-203.199.83.245-18142 Content-type: text/html; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

=0AHi Acee,
=0AIn continuation:
=0A
=0A2) Section 3.9 Multiple = Interfaces to a single link
=0AAll of the multiple interfaces to the lin= k will however appear in the router-LSA
=0A
=0A  Section 3.4.3.= 1  Router-LSAs
=0ANor are interfaces without any full adjacencies d= escribed.
=0A
=0A<vivek> Agreed it would be more clear if excep= tion in Section 3.4.3.1 is mentioned. Further, issue is, how should they be= represented in the Router-LSA. I think repeating each NBR(of active interf= ace on link) in standy interface description is redundant, though it preser= ves the current Router-LSA format.
=0A
=0A
=0AThanks
=0AVivek<= BR>=0A
=0A
=0A=0A

=0A

=0A=0A --Next_1118929776---0-203.199.83.245-18142-- From owner-ospf@PEACH.EASE.LSOFT.COM Thu Jun 16 10:18:36 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24614 for ; Thu, 16 Jun 2005 10:18:35 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.0107FDE3@cherry.ease.lsoft.com>; Thu, 16 Jun 2005 10:18:39 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 75615460 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 16 Jun 2005 10:18:38 -0400 Received: from 203.199.83.147 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 16 Jun 2005 10:18:37 -0400 Received: (qmail 11797 invoked by uid 510); 16 Jun 2005 14:20:11 -0000 Received: from unknown (203.126.136.223) by rediffmail.com via HTTP; 16 jun 2005 14:20:11 -0000 MIME-Version: 1.0 Content-type: multipart/alternative; boundary="Next_1118931611---0-203.199.83.147-11792" Message-ID: <20050616142011.11796.qmail@webmail25.rediffmail.com> Date: Thu, 16 Jun 2005 14:20:11 -0000 Reply-To: Mailing List Sender: Mailing List From: Vivek Dubey Subject: draft-ietf-ospf-ospfv3-mib-09.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This is a multipart mime message --Next_1118931611---0-203.199.83.147-11792 Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi,=0A=0Aospfv3AreaSummary:=0AThe variable should also effect NSSA areas. D= escription should be updated.=0A=0AThanks=0AVivek --Next_1118931611---0-203.199.83.147-11792 Content-type: text/html; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

=0AHi,
=0A
=0Aospfv3AreaSummary:
=0AThe variable should also ef= fect NSSA areas. Description should be updated.
=0A
=0AThanks
=0AV= ivek=0A

=0A

=0A=0A --Next_1118931611---0-203.199.83.147-11792-- From owner-ospf@PEACH.EASE.LSOFT.COM Thu Jun 16 11:05:09 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29335 for ; Thu, 16 Jun 2005 11:05:09 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.0108006C@cherry.ease.lsoft.com>; Thu, 16 Jun 2005 11:05:13 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 75620579 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 16 Jun 2005 11:05:11 -0400 Received: from 64.102.122.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 16 Jun 2005 11:05:11 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 16 Jun 2005 11:05:12 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j5GF4Oi5010422 for ; Thu, 16 Jun 2005 11:04:24 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 16 Jun 2005 11:04:13 -0400 Received: from [10.82.241.104] ([10.82.241.104]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 16 Jun 2005 11:04:14 -0400 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <20050616134936.18145.qmail@mailweb33.rediffmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jun 2005 15:04:14.0071 (UTC) FILETIME=[A8A74070:01C57284] Message-ID: <42B194EB.2060809@cisco.com> Date: Thu, 16 Jun 2005 11:04:11 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: draft-ietf-ospf-ospfv3-update-03 To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <20050616134936.18145.qmail@mailweb33.rediffmail.com> Precedence: list Content-Transfer-Encoding: 7bit Vivek Dubey wrote: >Hi Acee, >In continuation: > >2) Section 3.9 Multiple Interfaces to a single link >All of the multiple interfaces to the link will however appear in the router-LSA > > Section 3.4.3.1 Router-LSAs >Nor are interfaces without any full adjacencies described. > > Agreed it would be more clear if exception in Section 3.4.3.1 is mentioned. Further, issue is, how should they be represented in the Router-LSA. I think repeating each NBR(of active interface on link) in standy interface description is redundant, though it preserves the current Router-LSA format. > > Hi Vivek, Offhand, I can't think of a better encoding and doubt any other encoding would be backward compatible. Thanks, Acee > >Thanks >Vivek > > > > > From owner-ospf@PEACH.EASE.LSOFT.COM Thu Jun 23 01:26:49 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12406 for ; Thu, 23 Jun 2005 01:26:48 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.0108ACB0@cherry.ease.lsoft.com>; Thu, 23 Jun 2005 1:26:45 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 76464047 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 23 Jun 2005 01:26:38 -0400 Received: from 203.199.83.247 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 23 Jun 2005 01:26:37 -0400 Received: (qmail 2139 invoked by uid 510); 23 Jun 2005 05:28:07 -0000 Received: from unknown (203.126.136.223) by rediffmail.com via HTTP; 23 jun 2005 05:28:07 -0000 MIME-Version: 1.0 Content-type: multipart/alternative; boundary="Next_1119504487---0-203.199.83.247-2118" Message-ID: <20050623052807.2138.qmail@mailweb34.rediffmail.com> Date: Thu, 23 Jun 2005 05:28:07 -0000 Reply-To: Mailing List Sender: Mailing List From: Vivek Dubey Subject: ospfv3 - Route Entry To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This is a multipart mime message --Next_1119504487---0-203.199.83.247-2118 Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi,=0A=0ARFC 2328: Section 11=0A--------------------=0ADestination Type: Ro= uter entries are kept for area border routers and AS boundary routers=0A=0A= draft-ietf-ospf-ospfv3-update-04=0A--------------------------------=0ASecti= on 3.3 The Routing table Structure:=0AAn entry for each router in the area= is kept=0A=0A Calculation of reachability to stub networks and pref= ixes described in intra-area-prefix LSA is similar. What's the need to main= tain an entry for each router in the area ?=0A=0AThanks=0AVivek=0A=0A=0A --Next_1119504487---0-203.199.83.247-2118 Content-type: text/html; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

=0AHi,
=0A
=0ARFC 2328: Section 11
=0A--------------------
= =0ADestination Type: Router entries are kept for area border routers and AS= boundary routers
=0A
=0Adraft-ietf-ospf-ospfv3-update-04
=0A-----= ---------------------------
=0ASection 3.3  The Routing table Struc= ture:
=0AAn entry for each router in the area is kept
=0A
=0A<v= ivek> Calculation of reachability to stub networks and prefixes describe= d in intra-area-prefix LSA is similar. What's the need to maintain an entry= for each router in the area ?
=0A
=0AThanks
=0AVivek
=0A
= =0A
=0A=0A

=0A

=0A=0A --Next_1119504487---0-203.199.83.247-2118-- From owner-ospf@PEACH.EASE.LSOFT.COM Fri Jun 24 12:42:08 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23475 for ; Fri, 24 Jun 2005 12:42:08 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.0108D219@cherry.ease.lsoft.com>; Fri, 24 Jun 2005 12:42:07 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 76690693 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 24 Jun 2005 12:42:05 -0400 Received: from 171.68.10.86 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 24 Jun 2005 12:42:05 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by sj-iport-4.cisco.com with ESMTP; 24 Jun 2005 09:42:04 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j5OGg4bd027357 for ; Fri, 24 Jun 2005 12:42:04 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 24 Jun 2005 12:42:01 -0400 Received: from [10.82.242.173] ([10.82.242.173]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 24 Jun 2005 12:41:21 -0400 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <20050623052807.2138.qmail@mailweb34.rediffmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Jun 2005 16:41:21.0151 (UTC) FILETIME=[8D2B18F0:01C578DB] Message-ID: <42BC37D6.7090501@cisco.com> Date: Fri, 24 Jun 2005 12:41:58 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: ospfv3 - Route Entry To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <20050623052807.2138.qmail@mailweb34.rediffmail.com> Precedence: list Content-Transfer-Encoding: 7bit Vivek Dubey wrote: >Hi, > > Hi Vivek, >RFC 2328: Section 11 >-------------------- >Destination Type: Router entries are kept for area border routers and AS boundary routers > >draft-ietf-ospf-ospfv3-update-04 >-------------------------------- >Section 3.3 The Routing table Structure: >An entry for each router in the area is kept > > Calculation of reachability to stub networks and prefixes described in intra-area-prefix LSA is I guess similar. What's the need to maintain an entry for each router in the area ? > > Other implementations are possible. As you know, the OSPFv3 intra-area SPF calculation is done in 2 phases. First a Shortest Path Tree (SPT) is built from the router and network LSAs. In the second phase, the intra-area-prefix-LSAs are examined and routes are added to the routing table for reachable prefixes based on whether the reference LSA is reachable (among other checks). So, one either needs to lookup the route to the corresponding node in the SPT or the reference LSA. RFC 2740 chose the former and I think it is more straight forward. Thanks, Acee >Thanks >Vivek > > > > > From owner-ospf@PEACH.EASE.LSOFT.COM Fri Jun 24 16:00:13 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10795 for ; Fri, 24 Jun 2005 16:00:13 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.0108D678@cherry.ease.lsoft.com>; Fri, 24 Jun 2005 16:00:08 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 76707360 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 24 Jun 2005 16:00:04 -0400 Received: from 132.151.6.50 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 24 Jun 2005 15:50:02 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1DluBd-00056l-Kx; Fri, 24 Jun 2005 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-ID: Date: Fri, 24 Jun 2005 15:50:01 -0400 Reply-To: Mailing List Sender: Mailing List From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ospf-iana-01.txt Comments: To: i-d-announce@ietf.org To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF. Title : IANA Considerations for OSPF Author(s) : K. Kompella Filename : draft-ietf-ospf-iana-01.txt Pages : 15 Date : 2005-6-24 This memo creates a number of OSPF registries and provides guidance to IANA for assignment of code points within these registries. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-iana-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ospf-iana-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ospf-iana-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-6-24150822.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ospf-iana-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ospf-iana-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-6-24150822.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@PEACH.EASE.LSOFT.COM Mon Jun 27 03:05:03 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17644 for ; Mon, 27 Jun 2005 03:05:03 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.0108FC96@cherry.ease.lsoft.com>; Mon, 27 Jun 2005 3:05:02 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 76963960 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 27 Jun 2005 03:04:47 -0400 Received: from 203.199.83.248 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 27 Jun 2005 03:04:47 -0400 Received: (qmail 30223 invoked by uid 510); 27 Jun 2005 07:06:17 -0000 Received: from unknown (203.126.136.220) by rediffmail.com via HTTP; 27 jun 2005 07:06:17 -0000 MIME-Version: 1.0 Content-type: multipart/alternative; boundary="Next_1119855977---0-203.199.83.248-30201" Message-ID: <20050627070617.30219.qmail@webmail36.rediffmail.com> Date: Mon, 27 Jun 2005 07:06:17 -0000 Reply-To: Mailing List Sender: Mailing List From: Vivek Dubey Subject: Re: ospfv3 - Route Entry To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This is a multipart mime message --Next_1119855977---0-203.199.83.248-30201 Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Acee,=0A>Other implementations are possible. As you know, the OSPFv3 int= ra->area SPF calculation is done in 2 phases. First a Shortest Path Tree = =0A>(SPT) is built from the router and network LSAs. In the second phase, >= the intra-area-prefix-LSAs are examined and routes are added to the >routin= g table for reachable prefixes based on whether the reference >LSA is reach= able (among other checks). So, one either needs to lookup >the route to the= corresponding node in the SPT or the reference LSA. >RFC 2740 chose the fo= rmer and I think it is more straight forward.=0A=0AFollowing from above:=0A= =0Adraft-ietf-ospf-ospfv3-update-04=0A3.5.3 Installing LSAs in the databas= e=0A----------------------------------------=0ARouter-LSAs, Network-LSAs, I= ntra-Area-Prefix-LSAs, and Link-LSAs=0A The entire routing table is re= calculated, starting with the=0A shortest path calculation for each ar= ea (see Section 3.8)=0A=0A Change in contents of "Intra-Area-Prefix-= LSAs" does not require "entire routing table recalculation". Route entry fo= r referenced router/transit link should be checked and best route to prefix= es described in "Intra-Area-Prefix-LSAs" should be calculated=0A=0AThanks= =0AVivek=0A=0A=0A=0A=0A=0AOn Fri, 24 Jun 2005 Acee Lindem wrote :=0A>Vivek = Dubey wrote:=0A>=0A>>Hi,=0A>> =0A>Hi Vivek,=0A>=0A>>RFC 2328: Section 11= =0A>>--------------------=0A>>Destination Type: Router entries are kept for= area border routers and AS boundary routers=0A>>=0A>>draft-ietf-ospf-ospfv= 3-update-04=0A>>--------------------------------=0A>>Section 3.3 The Routi= ng table Structure:=0A>>An entry for each router in the area is kept=0A>>= =0A>> Calculation of reachability to stub networks and prefixes desc= ribed in intra-area-prefix LSA is I guess similar. What's the need to maint= ain an entry for each router in the area ?=0A>> =0A>Other implementations = are possible. As you know, the OSPFv3 intra-area SPF=0A>calculation is done= in 2 phases. First a Shortest Path Tree (SPT) is built from the=0A>router = and network LSAs. In the second phase, the intra-area-prefix-LSAs are=0A>ex= amined and routes are added to the routing table for reachable prefixes bas= ed=0A>on whether the reference LSA is reachable (among other checks). So, o= ne either=0A>needs to lookup the route to the corresponding node in the SPT= or the reference=0A>LSA. RFC 2740 chose the former and I think it is more = straight forward.=0A>=0A>Thanks,=0A>Acee=0A>=0A>>Thanks=0A>>Vivek=0A>>=0A>>= =0A>>=0A>> =0A --Next_1119855977---0-203.199.83.248-30201 Content-type: text/html; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

=0AHi Acee,
=0A>Other implementations are possible. As you know, t= he OSPFv3 intra->area SPF calculation is done in 2 phases. First a Short= est Path Tree
=0A>(SPT) is built from the router and network LSAs. I= n the second phase, >the intra-area-prefix-LSAs are examined and routes = are added to the >routing table for reachable prefixes based on whether = the reference >LSA is reachable (among other checks). So, one either nee= ds to lookup >the route to the corresponding node in the SPT or the refe= rence LSA. >RFC 2740 chose the former and I think it is more straight fo= rward.
=0A
=0AFollowing from above:
=0A
=0Adraft-ietf-ospf-ospf= v3-update-04
=0A3.5.3  Installing LSAs in the database
=0A------= ----------------------------------
=0ARouter-LSAs, Network-LSAs, Intra-A= rea-Prefix-LSAs, and Link-LSAs
=0A      The entire routin= g table is recalculated, starting with the
=0A      short= est path calculation for each area (see Section 3.8)
=0A
=0A<vivek= > Change in contents of "Intra-Area-Prefix-LSAs" does not requ= ire "entire routing table recalculation". Route entry for referen= ced router/transit link should be checked and best route to prefixes descri= bed in "Intra-Area-Prefix-LSAs" should be calculated
=0A
= =0AThanks
=0AVivek
=0A
=0A
=0A
=0A
=0A
=0AOn Fri, 24 J= un 2005 Acee Lindem wrote :
=0A>Vivek Dubey wrote:
=0A>
=0A&= gt;>Hi,
=0A>> 
=0A>Hi Vivek,
=0A>
=0A>&= gt;RFC 2328: Section 11
=0A>>--------------------
=0A>>De= stination Type: Router entries are kept for area border routers and AS boun= dary routers
=0A>>
=0A>>draft-ietf-ospf-ospfv3-update-04<= BR>=0A>>--------------------------------
=0A>>Section 3.3&nb= sp; The Routing table Structure:
=0A>>An entry for each router in = the area is kept
=0A>>
=0A>><vivek> Calculation of = reachability to stub networks and prefixes described in intra-area-prefix L= SA is I guess similar. What's the need to maintain an entry for each router= in the area ?
=0A>> 
=0A>Other implementations are po= ssible. As you know, the OSPFv3 intra-area SPF
=0A>calculation is don= e in 2 phases. First a Shortest Path Tree (SPT) is built from the
=0A>= ;router and network LSAs. In the second phase, the intra-area-prefix-LSAs a= re
=0A>examined and routes are added to the routing table for reachab= le prefixes based
=0A>on whether the reference LSA is reachable (amon= g other checks). So, one either
=0A>needs to lookup the route to the = corresponding node in the SPT or the reference
=0A>LSA. RFC 2740 chos= e the former and I think it is more straight forward.
=0A>
=0A>= Thanks,
=0A>Acee
=0A>
=0A>>Thanks
=0A>>Vivek<= BR>=0A>>
=0A>>
=0A>>
=0A>> 
=0A= =0A

=0A

=0A=0A --Next_1119855977---0-203.199.83.248-30201-- From owner-ospf@PEACH.EASE.LSOFT.COM Mon Jun 27 17:54:15 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26888 for ; Mon, 27 Jun 2005 17:54:15 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.01090600@cherry.ease.lsoft.com>; Mon, 27 Jun 2005 17:54:14 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 77081516 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 27 Jun 2005 17:53:58 -0400 Received: from 171.68.10.87 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 27 Jun 2005 17:53:58 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by sj-iport-5.cisco.com with ESMTP; 27 Jun 2005 14:54:00 -0700 X-IronPort-AV: i="3.93,235,1115017200"; d="scan'208"; a="194657007:sNHT31479384" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j5RLqOaE020884 for ; Mon, 27 Jun 2005 17:53:59 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 27 Jun 2005 17:53:44 -0400 Received: from [10.82.216.104] ([10.82.216.104]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 27 Jun 2005 17:53:44 -0400 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <20050627070617.30219.qmail@webmail36.rediffmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Jun 2005 21:53:44.0338 (UTC) FILETIME=[B037B720:01C57B62] Message-ID: <42C07567.8000901@cisco.com> Date: Mon, 27 Jun 2005 17:53:43 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: ospfv3 - Route Entry To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <20050627070617.30219.qmail@webmail36.rediffmail.com> Precedence: list Content-Transfer-Encoding: 7bit Vivek Dubey wrote: >Hi Acee, > > >>Other implementations are possible. As you know, the OSPFv3 intra->area SPF calculation is done in 2 phases. First a Shortest Path Tree >>(SPT) is built from the router and network LSAs. In the second phase, >the intra-area-prefix-LSAs are examined and routes are added to the >routing table for reachable prefixes based on whether the reference >LSA is reachable (among other checks). So, one either needs to lookup >the route to the corresponding node in the SPT or the reference LSA. >RFC 2740 chose the former and I think it is more straight forward. >> >> > >Following from above: > >draft-ietf-ospf-ospfv3-update-04 >3.5.3 Installing LSAs in the database >---------------------------------------- >Router-LSAs, Network-LSAs, Intra-Area-Prefix-LSAs, and Link-LSAs > The entire routing table is recalculated, starting with the > shortest path calculation for each area (see Section 3.8) > > Change in contents of "Intra-Area-Prefix-LSAs" does not require "entire routing table recalculation". Route entry for referenced router/transit link should be checked and best route to prefixes described in "Intra-Area-Prefix-LSAs" should be calculated > > Hi Vivek, As specified in section 16.1 of RFC 2328, optimizations are possible as long as the same SPF (Shortest Path Tree) is produced. It would be possible to specify an incremental calculation for intra-area-prefix-LSAs but since it hasn't been specified heretofore and implementations are free to implement one without specification, I'm not going to add it in this RFC 2740 re-spin. Note that there are a number of issues that would need to be covered (alternate routes, forwarding addresses, changes in VL endpoints, etc). Thanks, Acee >Thanks >Vivek > > > > > >On Fri, 24 Jun 2005 Acee Lindem wrote : > > >>Vivek Dubey wrote: >> >> >> >>>Hi, >>> >>> >>> >>Hi Vivek, >> >> >> >>>RFC 2328: Section 11 >>>-------------------- >>>Destination Type: Router entries are kept for area border routers and AS boundary routers >>> >>>draft-ietf-ospf-ospfv3-update-04 >>>-------------------------------- >>>Section 3.3 The Routing table Structure: >>>An entry for each router in the area is kept >>> >>> Calculation of reachability to stub networks and prefixes described in intra-area-prefix LSA is I guess similar. What's the need to maintain an entry for each router in the area ? >>> >>> >>> >>Other implementations are possible. As you know, the OSPFv3 intra-area SPF >>calculation is done in 2 phases. First a Shortest Path Tree (SPT) is built from the >>router and network LSAs. In the second phase, the intra-area-prefix-LSAs are >>examined and routes are added to the routing table for reachable prefixes based >>on whether the reference LSA is reachable (among other checks). So, one either >>needs to lookup the route to the corresponding node in the SPT or the reference >>LSA. RFC 2740 chose the former and I think it is more straight forward. >> >>Thanks, >>Acee >> >> >> >>>Thanks >>>Vivek >>> >>> >>> >>> >>> >>> > > > From owner-ospf@PEACH.EASE.LSOFT.COM Mon Jun 27 20:53:50 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18735 for ; Mon, 27 Jun 2005 20:53:50 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.0109087D@cherry.ease.lsoft.com>; Mon, 27 Jun 2005 20:53:49 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 77093271 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 27 Jun 2005 20:53:47 -0400 Received: from 209.119.0.160 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 27 Jun 2005 20:53:47 -0400 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by almond.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <6.008E3E45@almond.ease.lsoft.com>; Mon, 27 Jun 2005 20:53:47 -0400 Message-ID: Date: Mon, 27 Jun 2005 20:53:38 -0400 Reply-To: Mailing List Sender: Mailing List From: Paresh Khatri Subject: Two queries on calculating AS external routes To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Hi all, I've got a couple of queries on Section 16.4 of RFC2328 that I hope someone can help me with. 1) When determining that preferred routing table entry for the ASBR in step (4), what happens if we end up with two equal-cost intra-area routes (for the same area) to the ASBR (this is after all the pruning from 16.4.1 etc) ? Will both routes be installed in the routing table ? 2) Looking at step (6) now. If we have two, and only two, paths to a destination N, with the following characteristics: - same route-type (say, Type 2 external) - same type-2 metric - both are intra-area routes but for different non-backbone areas ( so we still end up with 2 paths after 16.4.1) - the intra-area distance to the ASBR is the same for both paths Will both paths be installed in the routing table ? If so, would that not contradict section 16.8, which states that all equal-cost paths for a route should be associated with the same area ? All responses appreciated. Cheers, Paresh Khatri From owner-ospf@PEACH.EASE.LSOFT.COM Mon Jun 27 22:19:58 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24079 for ; Mon, 27 Jun 2005 22:19:57 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.01090924@cherry.ease.lsoft.com>; Mon, 27 Jun 2005 22:19:57 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 77098206 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 27 Jun 2005 22:19:55 -0400 Received: from 171.68.10.87 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 27 Jun 2005 22:19:55 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-5.cisco.com with ESMTP; 27 Jun 2005 19:19:32 -0700 X-IronPort-AV: i="3.93,236,1115017200"; d="scan'208"; a="194739572:sNHT28940290" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j5S2JUVX016660 for ; Mon, 27 Jun 2005 19:19:30 -0700 (PDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 27 Jun 2005 22:18:28 -0400 Received: from [10.82.216.104] ([10.82.216.104]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 27 Jun 2005 22:18:28 -0400 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Jun 2005 02:18:28.0296 (UTC) FILETIME=[ABCB5C80:01C57B87] Message-ID: <42C0B373.3020506@cisco.com> Date: Mon, 27 Jun 2005 22:18:27 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Two queries on calculating AS external routes To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit Hi Paresh, See inline. Paresh Khatri wrote: >Hi all, > >I've got a couple of queries on Section 16.4 of RFC2328 that I hope someone >can help me with. > >1) >When determining that preferred routing table entry for the ASBR in step >(4), what happens if we end up with two equal-cost intra-area routes (for >the same area) to the ASBR (this is after all the pruning from 16.4.1 etc) ? > Will both routes be installed in the routing table ? > > Yes. Both paths should both be installed. >2) > >Looking at step (6) now. If we have two, and only two, paths to a >destination N, with the following characteristics: > - same route-type (say, Type 2 external) > - same type-2 metric > - both are intra-area routes but for different non-backbone areas ( so we >still end up with 2 paths after 16.4.1) > - the intra-area distance to the ASBR is the same for both paths >Will both paths be installed in the routing table ? If so, would that not >contradict section 16.8, which states that all equal-cost paths for a route >should be associated with the same area ? > > For equal cost paths to an ASBR, the path through the area with the highest ID should be chosen (refer to 16.4 (3)). Hope this helps, Acee >All responses appreciated. > >Cheers, >Paresh Khatri > > > From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jun 28 00:08:08 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02416 for ; Tue, 28 Jun 2005 00:08:08 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.01090CDB@cherry.ease.lsoft.com>; Tue, 28 Jun 2005 0:07:50 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 77105905 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 28 Jun 2005 00:07:48 -0400 Received: from 146.171.13.196 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 28 Jun 2005 00:00:57 -0400 Received: from aksmtpmdr1 (ish2-internal [146.171.1.20]) by smtp3.telecom.co.nz (Postfix) with ESMTP id E29041EB2 for ; Tue, 28 Jun 2005 15:55:17 +1200 (NZST) Received: from 146.171.227.25 by aksmtpmdr1 with ESMTP (Tumbleweed MMS SMTP Relay); Tue, 28 Jun 2005 16:00:54 +1200 X-Server-Uuid: 50880B64-500D-4147-A4F0-826C22747D83 Received: from AUNSWA003.au.tcnz.net ([10.136.168.51]) by akexsmtp02.telecom.tcnz.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 28 Jun 2005 16:00:52 +1200 Received: from aunswa002.au.tcnz.net ([10.136.168.50]) by AUNSWA003.au.tcnz.net with Microsoft SMTPSVC(5.0.2195.6747); Tue, 28 Jun 2005 14:00:52 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Thread-Topic: RE: Two queries on calculating AS external routes thread-index: AcV7lfbutWYy8rwNSp6w9zlbXCGO8g== X-OriginalArrivalTime: 28 Jun 2005 04:00:52.0611 (UTC) FILETIME=[FA176D30:01C57B95] X-WSS-ID: 6EDE14EC1KC3069650-09-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <44CF9D8D25966C4DB1072958419273DB406822@aunswa002.au.tcnz.net> Date: Tue, 28 Jun 2005 14:00:52 +1000 Reply-To: Mailing List Sender: Mailing List From: Paresh Khatri Subject: Re: Two queries on calculating AS external routes To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Thanks Acee, Looking back at my second query, I realise that I wasn't quite clear on wha= t= I was getting at (my apologies). It should be phrased as such: 2) Looking at step (6) now. If we have two, and only two, paths to a destination N, with the following characteristics:=20 - same route-type (say, Type 2 external)=20 - same type-2 metric - originated by two different ASBRs and the ASBRs are in different = non-backbone areas. - the intra-area distance to the ASBR is the same for both paths (but of = course, through a different area in each case) Will both paths be installed in the routing table =3F If so, would that not contradict section 16.8, which states that all equal-cost paths for a route should be associated with the same area =3F Would 16.4 (3) apply in this case or is it only applicable when you have = multiple paths to the *same* ASBR =3F Thanks again, Paresh. =20 -----Original Message----- =46rom: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of Acee Lindem Sent: Tuesday, 28 June 2005 12:18 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: Two queries on calculating AS external routes Hi Paresh, See inline. Paresh Khatri wrote: >Hi all, > >I've got a couple of queries on Section 16.4 of RFC2328 that I hope someone >can help me with. > >1) >When determining that preferred routing table entry for the ASBR in step >(4), what happens if we end up with two equal-cost intra-area routes (for >the same area) to the ASBR (this is after all the pruning from 16.4.1 etc)= = =3F > Will both routes be installed in the routing table =3F > =20 > Yes. Both paths should both be installed. >2) > >Looking at step (6) now. If we have two, and only two, paths to a >destination N, with the following characteristics:=20 > - same route-type (say, Type 2 external)=20 > - same type-2 metric > - both are intra-area routes but for different non-backbone areas ( so we >still end up with 2 paths after 16.4.1) > - the intra-area distance to the ASBR is the same for both paths >Will both paths be installed in the routing table =3F If so, would that = not >contradict section 16.8, which states that all equal-cost paths for a route >should be associated with the same area =3F > =20 > =46or equal cost paths to an ASBR, the path through the area with the=20 highest ID should be chosen (refer to 16.4 (3)). Hope this helps, Acee >All responses appreciated. > >Cheers, >Paresh Khatri=20 > > =20 > This communication, including any attachments, is confidential. If=20 you are not the intended recipient, you should not read it - please=20 contact me immediately, destroy it, and do not copy or use any part of=20 this communication or disclose anything about it. From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jun 28 09:59:34 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10187 for ; Tue, 28 Jun 2005 09:59:34 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.01091228@cherry.ease.lsoft.com>; Tue, 28 Jun 2005 9:59:33 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 77176041 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 28 Jun 2005 09:59:29 -0400 Received: from 64.102.122.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 28 Jun 2005 09:59:28 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 28 Jun 2005 09:59:32 -0400 X-IronPort-AV: i="3.93,239,1115006400"; d="scan'208"; a="60038237:sNHT353812246" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j5SDxUaC025971 for ; Tue, 28 Jun 2005 09:59:30 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 28 Jun 2005 09:59:10 -0400 Received: from [10.82.216.104] ([10.82.216.104]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 28 Jun 2005 09:59:10 -0400 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <44CF9D8D25966C4DB1072958419273DB406822@aunswa002.au.tcnz.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Jun 2005 13:59:10.0044 (UTC) FILETIME=[8EA101C0:01C57BE9] Message-ID: <42C157AD.4080501@cisco.com> Date: Tue, 28 Jun 2005 09:59:09 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Two queries on calculating AS external routes To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <44CF9D8D25966C4DB1072958419273DB406822@aunswa002.au.tcnz.net> Precedence: list Content-Transfer-Encoding: 7bit Paresh Khatri wrote: >Thanks Acee, > >Looking back at my second query, I realise that I wasn't quite clear on what I was getting at (my apologies). It should be phrased as such: > >2) >Looking at step (6) now. If we have two, and only two, paths to a >destination N, with the following characteristics: > - same route-type (say, Type 2 external) > - same type-2 metric > - originated by two different ASBRs and the ASBRs are in different non-backbone areas. > - the intra-area distance to the ASBR is the same for both paths (but of course, through a > different area in each case) >Will both paths be installed in the routing table ? If so, would that not >contradict section 16.8, which states that all equal-cost paths for a route >should be associated with the same area ? > >Would 16.4 (3) apply in this case or is it only applicable when you have multiple paths to the *same* ASBR ? > > Hi Paresh, Although not explicitly stated, the intent of the RFC is to have a single exit point from the OSPF routing domain for the AS external route. This was clarified in the latest NSSA RFC with the LSA with the highest router ID given preference - see section 2.5 of RFC 3101. Hope this helps, Acee >Thanks again, >Paresh. > > > > >-----Original Message----- >From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of Acee >Lindem >Sent: Tuesday, 28 June 2005 12:18 PM >To: OSPF@PEACH.EASE.LSOFT.COM >Subject: Re: Two queries on calculating AS external routes > > >Hi Paresh, >See inline. > >Paresh Khatri wrote: > > > >>Hi all, >> >>I've got a couple of queries on Section 16.4 of RFC2328 that I hope someone >>can help me with. >> >>1) >>When determining that preferred routing table entry for the ASBR in step >>(4), what happens if we end up with two equal-cost intra-area routes (for >>the same area) to the ASBR (this is after all the pruning from 16.4.1 etc) ? >>Will both routes be installed in the routing table ? >> >> >> >> >Yes. Both paths should both be installed. > > > >>2) >> >>Looking at step (6) now. If we have two, and only two, paths to a >>destination N, with the following characteristics: >>- same route-type (say, Type 2 external) >>- same type-2 metric >>- both are intra-area routes but for different non-backbone areas ( so we >>still end up with 2 paths after 16.4.1) >>- the intra-area distance to the ASBR is the same for both paths >>Will both paths be installed in the routing table ? If so, would that not >>contradict section 16.8, which states that all equal-cost paths for a route >>should be associated with the same area ? >> >> >> >> >For equal cost paths to an ASBR, the path through the area with the >highest ID should be >chosen (refer to 16.4 (3)). > >Hope this helps, >Acee > > > >>All responses appreciated. >> >>Cheers, >>Paresh Khatri >> >> >> >> >> > > > > > >This communication, including any attachments, is confidential. If > you are not the intended recipient, you should not read it - please > contact me immediately, destroy it, and do not copy or use any part of > this communication or disclose anything about it. > > > From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jun 28 18:42:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnOmq-0000hU-RJ for ospf-archive@megatron.ietf.org; Tue, 28 Jun 2005 18:42:37 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06047 for ; Tue, 28 Jun 2005 18:42:33 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.01091AF3@cherry.ease.lsoft.com>; Tue, 28 Jun 2005 18:42:30 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 77224818 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 28 Jun 2005 18:42:14 -0400 Received: from 146.171.13.196 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 28 Jun 2005 18:42:14 -0400 Received: from aksmtpmdr1 (ish2-internal [146.171.1.20]) by smtp3.telecom.co.nz (Postfix) with ESMTP id E32B31F64 for ; Wed, 29 Jun 2005 10:36:35 +1200 (NZST) Received: from 146.171.227.24 by aksmtpmdr1 with ESMTP (Tumbleweed MMS SMTP Relay); Wed, 29 Jun 2005 10:41:42 +1200 X-Server-Uuid: 50880B64-500D-4147-A4F0-826C22747D83 Received: from AUNSWA003.au.tcnz.net ([10.136.168.51]) by akexsmtp01.telecom.tcnz.net with Microsoft SMTPSVC(6.0.3790.211); Wed, 29 Jun 2005 10:41:38 +1200 Received: from aunswa002.au.tcnz.net ([10.136.168.50]) by AUNSWA003.au.tcnz.net with Microsoft SMTPSVC(5.0.2195.6747); Wed, 29 Jun 2005 08:41:37 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Thread-Topic: Two queries on calculating AS external routes thread-index: AcV76aPtnSPKc9Z9Rkq/HCBn4jxwdAASNM4A X-OriginalArrivalTime: 28 Jun 2005 22:41:37.0518 (UTC) FILETIME=[8B2DF0E0:01C57C32] X-WSS-ID: 6EDF0D9B1KC3213393-18-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <44CF9D8D25966C4DB1072958419273DB01294DFF@aunswa002.au.tcnz.net> Date: Wed, 29 Jun 2005 08:41:37 +1000 Reply-To: Mailing List Sender: Mailing List From: Paresh Khatri Subject: Re: Two queries on calculating AS external routes To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Thanks Acee, I guess that's the bit I was missing. Regards, Paresh. -----Original Message----- =46rom: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of Acee Lindem Sent: Tuesday, 28 June 2005 11:59 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: Two queries on calculating AS external routes Paresh Khatri wrote: >Thanks Acee, > >Looking back at my second query, I realise that I wasn't quite clear on = what I was getting at (my apologies). It should be phrased as such: > >2) >Looking at step (6) now. If we have two, and only two, paths to a >destination N, with the following characteristics:=20 > - same route-type (say, Type 2 external)=20 > - same type-2 metric > - originated by two different ASBRs and the ASBRs are in different = non-backbone areas. > - the intra-area distance to the ASBR is the same for both paths (but of = course, through a > different area in each case) >Will both paths be installed in the routing table =3F If so, would that = not >contradict section 16.8, which states that all equal-cost paths for a route >should be associated with the same area =3F > >Would 16.4 (3) apply in this case or is it only applicable when you have = multiple paths to the *same* ASBR =3F > =20 > Hi Paresh, Although not explicitly stated, the intent of the RFC is to have a=20 single exit point =66rom the OSPF routing domain for the AS external route. This was=20 clarified in the latest NSSA RFC with the LSA with the highest router ID given preference=20 - see section 2.5 of RFC 3101. Hope this helps, Acee >Thanks again, >Paresh. > > =20 > > >-----Original Message----- >From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of Acee >Lindem >Sent: Tuesday, 28 June 2005 12:18 PM >To: OSPF@PEACH.EASE.LSOFT.COM >Subject: Re: Two queries on calculating AS external routes > > >Hi Paresh, >See inline. > >Paresh Khatri wrote: > > =20 > >>Hi all, >> >>I've got a couple of queries on Section 16.4 of RFC2328 that I hope = someone >>can help me with. >> >>1) >>When determining that preferred routing table entry for the ASBR in step >>(4), what happens if we end up with two equal-cost intra-area routes (for >>the same area) to the ASBR (this is after all the pruning from 16.4.1 etc= )= =3F >>Will both routes be installed in the routing table =3F >>=20 >> >> =20 >> >Yes. Both paths should both be installed. > > =20 > >>2) >> >>Looking at step (6) now. If we have two, and only two, paths to a >>destination N, with the following characteristics:=20 >>- same route-type (say, Type 2 external)=20 >>- same type-2 metric >>- both are intra-area routes but for different non-backbone areas ( so we >>still end up with 2 paths after 16.4.1) >>- the intra-area distance to the ASBR is the same for both paths >>Will both paths be installed in the routing table =3F If so, would that = not >>contradict section 16.8, which states that all equal-cost paths for a = route >>should be associated with the same area =3F >>=20 >> >> =20 >> >For equal cost paths to an ASBR, the path through the area with the=20 >highest ID should be >chosen (refer to 16.4 (3)). > >Hope this helps, >Acee > > =20 > >>All responses appreciated. >> >>Cheers, >>Paresh Khatri=20 >> >>=20 >> >> =20 >> > > > > > >This communication, including any attachments, is confidential. If=20 > you are not the intended recipient, you should not read it - please=20 > contact me immediately, destroy it, and do not copy or use any part of=20 > this communication or disclose anything about it. > > =20 > This communication, including any attachments, is confidential. If=20 you are not the intended recipient, you should not read it - please=20 contact me immediately, destroy it, and do not copy or use any part of=20 this communication or disclose anything about it. From owner-ospf@PEACH.EASE.LSOFT.COM Thu Jun 30 04:43:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dnue5-0008ID-5h for ospf-archive@megatron.ietf.org; Thu, 30 Jun 2005 04:43:41 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17026 for ; Thu, 30 Jun 2005 04:43:38 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.01093F94@cherry.ease.lsoft.com>; Thu, 30 Jun 2005 4:43:34 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 77404008 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 30 Jun 2005 04:43:32 -0400 Received: from 147.234.1.11 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 30 Jun 2005 04:43:32 -0400 X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 X-MIMETrack: Serialize by Router on ILSMTP01/ECI Telecom(Release 6.5.1|January 21, 2004) at 06/30/2005 11:49:09 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Message-ID: Date: Thu, 30 Jun 2005 11:43:30 +0300 Reply-To: Mailing List Sender: Mailing List From: Ilan Bercovich Subject: Overflows handling To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Hi What is correct LSA/database/routing-table overflow handling? Any alarm/warning? Which entries are to be selected? Ilan