From owner-ospf@DISCUSS.MICROSOFT.COM Fri Jan 3 12:30:39 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13778 for ; Fri, 3 Jan 2003 12:30:38 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.00862D6A@cherry.ease.lsoft.com>; Fri, 3 Jan 2003 12:33:48 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 504985 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 3 Jan 2003 12:33:47 -0500 Received: from 171.71.163.11 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 3 Jan 2003 12:33:47 -0500 Received: from mira-sjc5-f.cisco.com (IDENT:mirapoint@mira-sjc5-f.cisco.com [171.71.163.13]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h03HXkFp022627 for ; Fri, 3 Jan 2003 09:33:46 -0800 (PST) Received: from cisco.com (sjc-vpn3-1070.cisco.com [10.21.68.46]) by mira-sjc5-f.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABS27438; Fri, 3 Jan 2003 09:38:29 -0800 (PST) X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-19.7.x i686) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3E15C9DA.A627860@cisco.com> Date: Fri, 3 Jan 2003 09:35:22 -0800 Reply-To: Mailing List Sender: Mailing List From: Michael J Barnes Subject: Re: How could OPSFv3 support IPv4 ? To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hello Vishwas and everyone, I'm thinking along these lines too. If nobody else is, I'm prepared to start writing a draft document for supporting IPv4 addresses in OSPFv3. It seems that there is enough interest in this capability to warrant it. These are the points I have, taken from previous e-mails and thoughts of my own: - Create IPv4 Address Family versions of the Link, Intra-Area-Prefix, Inter-Area-Prefix, and AS-External LSAs. These LSAs would be adaptations of the current OSPFv3 LSAs. Unless otherwise specified, these LSAs will be treated in the same manner as their IPv6 counterparts. - Whether or not the U-bit is set in IPv4 AF LSAs should be user configurable, but defaulting to set. - Have a v4-bit in the Options field, indicating whether or not the router forwards IPv4 packets. - If all router LSAs have the v4 bit set, then a single SPF calculation can be done. Otherwise there must be a separate v4 SPF calculation. An implementation can always do two SPF calculations. - Whether or not an ABR originates IPv4 AF Inter-Area-Summary LSAs should be user configurable. - If the v6-bit is set for the router, then any interface over which an adjacency can be formed must forward IPv6 packets. Interfaces that forward IPv4 packets but not IPv6 packets will, in general, be treated like connections to stub networks. The two issues I'm most concerned about are 1) how to handle multi-access networks with some non-v4AF capable routers, and 2) routers with both the v6-bit and v4-bit set, but which have some interfaces on a transit links which are not able to forward IPv4 packets. Routers on a broadcast link which do not support IPv4 AF should have their router priority set to 0 so that they do not become the DR. However, we need to consider how the case of the DR not v4AF capable. Some ideas: 1 - The v4AF capable routers on the link select a proxy DR which will originate the v4 Intra-Area-Prefix LSA for the link. Special rules are needed for some cases, non-full mesh NBMA networks for example. In those cases the v4AF capable routers will not originate v4 Link LSAs for the network. (Thus the v4 bit will not be set in the Network LSA, and the network will not function as a transit network for IPv4.) 2 - Each v4AF capable router could originate a v4 Intra-Area-Prefix LSA associated with its Router LSA, advertising just its own v4 prefixes for the link. Some special rules would also be needed for this solution. 3 - Require the v4AF capable routers to automatically raise their priorities by the amount of the highest priority of the non v4AF capable routers. I also have a few ideas about routers which have the v6-bit and v4-bit set but are able to forward IPv4 packets on only some of the interfaces which can forward IPv6 packets. (Excepting interfaces connected to stub networks.) 1 - Define one of the bits in the unused byte between the Type and Metric fields as a v4-bit. If this bit is not set the interface would not be considered during the IPv4 SPF calculation. This bit will only be set if there is a v4AF capable neighor on this link. 2 - The interface must be either 2-WAY or FULL with at least one v4AF capable neighbor, and must be able to forward IPv4 packets on that interface. Otherwise the interface will be treated as if it were connected to a stub network and it will not be listed in the Router LSA. 3 - If some, but not all, interfaces have IPv4 enabled then originate two Router LSAs, one with the v6-bit set and the other with the v4-bit set. Each Router LSA would then describe the interfaces which are capable of forwarding their corresponding IP packets. I look forward to further discussion. Regards, Michael > -----Original Message----- > From: Manral, Vishwas [mailto:VishwasM@NETPLANE.COM] > Sent: Thursday, December 12, 2002 10:44 AM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Re: How could OPSFv3 support IPv4 ? > > Hi Vincent, > > I think importing v2 LSA's directly would not be a good idea in this case, > as most of the information other than the IPv4 addresses are already there > in OSPFv3 LSA's. Importing it would make it compulsary for OSPFv3 to > understand OSPFv2 LSA types, besides the entire SPF processing(as well as > LSA generation), would have to change to make use of information contained > in OSPFv2 LSA's. > > Using just the new OSPFv3 LSA's with equivalents for the IPv6 address > containing LSA's, would make the job a lot easier, and we could infact do > the SPF irrespective of protocol, and IPv4/IPv6 address nodes would be added > as stubs on the tree. > > Thanks, > Vishwas > > -----Original Message----- > From: Vincent Jardin [mailto:jardin@6WIND.COM] > Sent: Thursday, December 12, 2002 1:10 AM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Re: How could OPSFv3 support IPv4 ? > > Hi Vishwas, > > If we just have some new LSA types instead of the IPv4 mapped IPv6 > address, would it be enough to import the OSPFv2 LSA's within OSPFv3 ? > > Moreover, it could use the scope feature of OSPFv3. > > Vincent > > On Wed, 11 Dec 2002, Acee Lindem wrote: > > > Manral, Vishwas wrote: > > > Hi Yasu, > > > > > > I think you missed "Link-LSA" equivalents. I think they would be > required > > > too !!! > > > > Yup. I think these would be needed too. Also, if we were serious about > this > > I don't think using the IPv4 mapped IPv6 address is the best way to go. It > > would be better to have new LSA types for for IPv4 or with an AF and > generic > > address. > > > > > > > > Thanks, > > > Vishwas > > > > > > -----Original Message----- > > > From: Yasuhiro Ohara [mailto:yasu@SFC.WIDE.AD.JP] > > > Sent: Wednesday, December 11, 2002 7:48 PM > > > To: OSPF@DISCUSS.MICROSOFT.COM > > > Subject: Re: How could OPSFv3 support IPv4 ? > > > > > > > > > > > >>I am wondering how OSPFv3 could support IPv4. > > >> > > >>According to the RFC2740, the 24-bit OSPFv3 options field describes the > > >>router capabilities. For example, the R-bit and the V6-bit are used in > > >>order to announce IPv6 forwarding capabilities. However, what's happened > > >>if this V6-bit is clear ? > > > > > > > > > RFC2740's section 2.7 gives the exact answer: > > > > > > V6-bit specializes the R-bit; if the V6-bit is clear an OSPF > > > speaker can participate in OSPF topology distribution without > > > being used to forward IPv6 datagrams. If the R-bit is set and the > > > V6-bit is clear, IPv6 datagrams are not forwarded but diagrams > > > belonging to another protocol family may be forwarded. > > > > > > In routers do not support other protocol family other than IPv6, > > > the router having V6-bit off should be treated as a non-working router > > > from the rest of the network. > > > > > > > > >>If there would be a V4-bit in order to announce the IPv4 capabilities, > > >>how could OSPFv3 be extended in order to support IPv4 like Integrated > > >>ISIS ? > > > > > > > > > You'll need only to define IPv4 version of Intra-Area-Prefix-LSA, > > > Inter-Area-Prefix-LSA, AS-External-LSA. Using IPv6 address holding > > > embedded IPv4 address is another option. I guess IPv4-mapped will be > > > the right choice semantically in that case, but it may not be > > > accepted as I saw someone states "IPv4-mapped address should not > > > appear on the wire" somewhere. I believe it means as IP source or > > > destination, though. > > > > > > regards, > > > yasu > > > > Acee > > From owner-ospf@DISCUSS.MICROSOFT.COM Fri Jan 3 21:53:18 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23997 for ; Fri, 3 Jan 2003 21:53:17 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00863C10@cherry.ease.lsoft.com>; Fri, 3 Jan 2003 21:56:28 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 516128 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 3 Jan 2003 21:56:28 -0500 Received: from 65.223.109.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 3 Jan 2003 21:46:28 -0500 Received: from toro ([127.0.0.1] helo=toro. ident=takada) by toro with esmtp (Exim 3.35 #1 (Debian)) id 18UeGz-0000uC-00 for ; Fri, 03 Jan 2003 18:42:54 -0800 User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/21.2 (i686-pc-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Message-ID: <87n0mhocsy.wl@toro.zebra.org> Date: Fri, 3 Jan 2003 18:42:53 -0800 Reply-To: Mailing List Sender: Mailing List From: Toshiaki Takada Organization: IP Infusion, Inc. Subject: Instance ID for virtual interface To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi, I have one question. OSPFv3 packet header includes 1 octet "Instance ID" so that it allows running multiple instances on a single link. I thought "Instance ID" for Virtual interfaces could be configured as well. I looked through OSPFv3 MIB draft, however "ospfv3VirtIfTable" table doesn't have Instance ID object in the entry. My question is, should we have "ospfv3VirtIfInstId" object like "ospfv3IfTable", or isn't it allowed to configure instance ID over virtual link? -- Toshiaki Takada From owner-ospf@DISCUSS.MICROSOFT.COM Sun Jan 5 13:54:54 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09332 for ; Sun, 5 Jan 2003 13:54:54 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.00866DEE@cherry.ease.lsoft.com>; 5 Jan 2003 13:58:04 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 527516 for OSPF@DISCUSS.MICROSOFT.COM; Sun, 5 Jan 2003 13:58:04 -0500 Received: from 152.163.225.100 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Sun, 5 Jan 2003 13:48:04 -0500 Received: from ben8ietf@netscape.net by imo-r04.mx.aol.com (mail_out_v34.13.) id 7.af.67b040c (16239) for ; Sun, 5 Jan 2003 13:47:51 -0500 (EST) Received: from netscape.net (208-59-125-137.s391.tnt1.frdr.md.dialup.rcn.com [208.59.125.137]) by air-in03.mx.aol.com (v90.10) with ESMTP id MAILININ33-0105134750; Sun, 05 Jan 2003 13:47:50 -0500 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Mailer: Unknown (No Version) Message-ID: <3E187DB8.7030301@netscape.net> Date: Sun, 5 Jan 2003 13:47:20 -0500 Reply-To: Mailing List Sender: Mailing List From: Ben Abarbanel Subject: Re: ospfNbrAddressLessIndex To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Mukund: Do you have relative by the name of Jothirlata Jagannathan working at Marconi? Ben Mukund Jagannathan wrote: >Hi: >In the case of unnumbered interface does the ospfNbrAddressLessIndex >represent the ifindex of the local interface or is it the ifindex of the >unnumbered adjacent interface. This is not the ospfIfAddressLessIf. > >[Note: The local router does get the ifindex of the adjacent router over an >unnumbered interface in the router lsa.] > >Thanks >Mukund > > From owner-ospf@DISCUSS.MICROSOFT.COM Mon Jan 6 00:06:37 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16300 for ; Mon, 6 Jan 2003 00:06:36 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00867C93@cherry.ease.lsoft.com>; Mon, 6 Jan 2003 0:05:03 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 536363 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 6 Jan 2003 00:05:03 -0500 Received: from 12.27.183.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 6 Jan 2003 00:05:03 -0500 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <4B0HSWSY>; Mon, 6 Jan 2003 00:04:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Mon, 6 Jan 2003 00:07:00 -0500 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: How could OPSFv3 support IPv4 ? To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Michael, I think its ok if you go forward with the draft, I am sure a lot of people(including me) would be willing to help. Thanks, Vishwas -----Original Message----- From: Michael J Barnes [mailto:mjbarnes@CISCO.COM] Sent: Friday, January 03, 2003 11:05 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: How could OPSFv3 support IPv4 ? Hello Vishwas and everyone, I'm thinking along these lines too. If nobody else is, I'm prepared to start writing a draft document for supporting IPv4 addresses in OSPFv3. It seems that there is enough interest in this capability to warrant it. These are the points I have, taken from previous e-mails and thoughts of my own: - Create IPv4 Address Family versions of the Link, Intra-Area-Prefix, Inter-Area-Prefix, and AS-External LSAs. These LSAs would be adaptations of the current OSPFv3 LSAs. Unless otherwise specified, these LSAs will be treated in the same manner as their IPv6 counterparts. - Whether or not the U-bit is set in IPv4 AF LSAs should be user configurable, but defaulting to set. - Have a v4-bit in the Options field, indicating whether or not the router forwards IPv4 packets. - If all router LSAs have the v4 bit set, then a single SPF calculation can be done. Otherwise there must be a separate v4 SPF calculation. An implementation can always do two SPF calculations. - Whether or not an ABR originates IPv4 AF Inter-Area-Summary LSAs should be user configurable. - If the v6-bit is set for the router, then any interface over which an adjacency can be formed must forward IPv6 packets. Interfaces that forward IPv4 packets but not IPv6 packets will, in general, be treated like connections to stub networks. The two issues I'm most concerned about are 1) how to handle multi-access networks with some non-v4AF capable routers, and 2) routers with both the v6-bit and v4-bit set, but which have some interfaces on a transit links which are not able to forward IPv4 packets. Routers on a broadcast link which do not support IPv4 AF should have their router priority set to 0 so that they do not become the DR. However, we need to consider how the case of the DR not v4AF capable. Some ideas: 1 - The v4AF capable routers on the link select a proxy DR which will originate the v4 Intra-Area-Prefix LSA for the link. Special rules are needed for some cases, non-full mesh NBMA networks for example. In those cases the v4AF capable routers will not originate v4 Link LSAs for the network. (Thus the v4 bit will not be set in the Network LSA, and the network will not function as a transit network for IPv4.) 2 - Each v4AF capable router could originate a v4 Intra-Area-Prefix LSA associated with its Router LSA, advertising just its own v4 prefixes for the link. Some special rules would also be needed for this solution. 3 - Require the v4AF capable routers to automatically raise their priorities by the amount of the highest priority of the non v4AF capable routers. I also have a few ideas about routers which have the v6-bit and v4-bit set but are able to forward IPv4 packets on only some of the interfaces which can forward IPv6 packets. (Excepting interfaces connected to stub networks.) 1 - Define one of the bits in the unused byte between the Type and Metric fields as a v4-bit. If this bit is not set the interface would not be considered during the IPv4 SPF calculation. This bit will only be set if there is a v4AF capable neighor on this link. 2 - The interface must be either 2-WAY or FULL with at least one v4AF capable neighbor, and must be able to forward IPv4 packets on that interface. Otherwise the interface will be treated as if it were connected to a stub network and it will not be listed in the Router LSA. 3 - If some, but not all, interfaces have IPv4 enabled then originate two Router LSAs, one with the v6-bit set and the other with the v4-bit set. Each Router LSA would then describe the interfaces which are capable of forwarding their corresponding IP packets. I look forward to further discussion. Regards, Michael > -----Original Message----- > From: Manral, Vishwas [mailto:VishwasM@NETPLANE.COM] > Sent: Thursday, December 12, 2002 10:44 AM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Re: How could OPSFv3 support IPv4 ? > > Hi Vincent, > > I think importing v2 LSA's directly would not be a good idea in this case, > as most of the information other than the IPv4 addresses are already there > in OSPFv3 LSA's. Importing it would make it compulsary for OSPFv3 to > understand OSPFv2 LSA types, besides the entire SPF processing(as well as > LSA generation), would have to change to make use of information contained > in OSPFv2 LSA's. > > Using just the new OSPFv3 LSA's with equivalents for the IPv6 address > containing LSA's, would make the job a lot easier, and we could infact do > the SPF irrespective of protocol, and IPv4/IPv6 address nodes would be added > as stubs on the tree. > > Thanks, > Vishwas > > -----Original Message----- > From: Vincent Jardin [mailto:jardin@6WIND.COM] > Sent: Thursday, December 12, 2002 1:10 AM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Re: How could OPSFv3 support IPv4 ? > > Hi Vishwas, > > If we just have some new LSA types instead of the IPv4 mapped IPv6 > address, would it be enough to import the OSPFv2 LSA's within OSPFv3 ? > > Moreover, it could use the scope feature of OSPFv3. > > Vincent > > On Wed, 11 Dec 2002, Acee Lindem wrote: > > > Manral, Vishwas wrote: > > > Hi Yasu, > > > > > > I think you missed "Link-LSA" equivalents. I think they would be > required > > > too !!! > > > > Yup. I think these would be needed too. Also, if we were serious about > this > > I don't think using the IPv4 mapped IPv6 address is the best way to go. It > > would be better to have new LSA types for for IPv4 or with an AF and > generic > > address. > > > > > > > > Thanks, > > > Vishwas > > > > > > -----Original Message----- > > > From: Yasuhiro Ohara [mailto:yasu@SFC.WIDE.AD.JP] > > > Sent: Wednesday, December 11, 2002 7:48 PM > > > To: OSPF@DISCUSS.MICROSOFT.COM > > > Subject: Re: How could OPSFv3 support IPv4 ? > > > > > > > > > > > >>I am wondering how OSPFv3 could support IPv4. > > >> > > >>According to the RFC2740, the 24-bit OSPFv3 options field describes the > > >>router capabilities. For example, the R-bit and the V6-bit are used in > > >>order to announce IPv6 forwarding capabilities. However, what's happened > > >>if this V6-bit is clear ? > > > > > > > > > RFC2740's section 2.7 gives the exact answer: > > > > > > V6-bit specializes the R-bit; if the V6-bit is clear an OSPF > > > speaker can participate in OSPF topology distribution without > > > being used to forward IPv6 datagrams. If the R-bit is set and the > > > V6-bit is clear, IPv6 datagrams are not forwarded but diagrams > > > belonging to another protocol family may be forwarded. > > > > > > In routers do not support other protocol family other than IPv6, > > > the router having V6-bit off should be treated as a non-working router > > > from the rest of the network. > > > > > > > > >>If there would be a V4-bit in order to announce the IPv4 capabilities, > > >>how could OSPFv3 be extended in order to support IPv4 like Integrated > > >>ISIS ? > > > > > > > > > You'll need only to define IPv4 version of Intra-Area-Prefix-LSA, > > > Inter-Area-Prefix-LSA, AS-External-LSA. Using IPv6 address holding > > > embedded IPv4 address is another option. I guess IPv4-mapped will be > > > the right choice semantically in that case, but it may not be > > > accepted as I saw someone states "IPv4-mapped address should not > > > appear on the wire" somewhere. I believe it means as IP source or > > > destination, though. > > > > > > regards, > > > yasu > > > > Acee > > From owner-ospf@DISCUSS.MICROSOFT.COM Mon Jan 6 11:43:39 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06912 for ; Mon, 6 Jan 2003 11:43:38 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00868AB0@cherry.ease.lsoft.com>; Mon, 6 Jan 2003 11:46:51 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 546887 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 6 Jan 2003 11:46:51 -0500 Received: from 12.27.183.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 6 Jan 2003 11:46:51 -0500 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <4B0HSXNM>; Mon, 6 Jan 2003 11:46:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Mon, 6 Jan 2003 11:48:28 -0500 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: Instance ID for virtual interface To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Takada-san, Though Dan will clarify further, I think we should allow configuring the "Instance Id" for a virtual link too. Thanks, Vishwas -----Original Message----- From: Toshiaki Takada [mailto:toshiaki@IPINFUSION.COM] Sent: Saturday, January 04, 2003 8:13 AM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Instance ID for virtual interface Hi, I have one question. OSPFv3 packet header includes 1 octet "Instance ID" so that it allows running multiple instances on a single link. I thought "Instance ID" for Virtual interfaces could be configured as well. I looked through OSPFv3 MIB draft, however "ospfv3VirtIfTable" table doesn't have Instance ID object in the entry. My question is, should we have "ospfv3VirtIfInstId" object like "ospfv3IfTable", or isn't it allowed to configure instance ID over virtual link? -- Toshiaki Takada From owner-ospf@DISCUSS.MICROSOFT.COM Mon Jan 6 14:54:47 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12720 for ; Mon, 6 Jan 2003 14:54:47 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.008691F9@cherry.ease.lsoft.com>; Mon, 6 Jan 2003 14:57:59 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 548074 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 6 Jan 2003 14:57:59 -0500 Received: from 192.11.222.161 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 6 Jan 2003 14:57:59 -0500 Received: from ma8117exch001u.wins.lucent.com (h152-148-89-175.lucent.com [152.148.89.175]) by ihemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h06JvvC00012 for ; Mon, 6 Jan 2003 14:57:58 -0500 (EST) Received: by ma8117exch001u.inse.lucent.com with Internet Mail Service (5.5.2653.19) id ; Mon, 6 Jan 2003 14:57:57 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Message-ID: Date: Mon, 6 Jan 2003 14:57:56 -0500 Reply-To: Mailing List Sender: Mailing List From: "Joyal, Daniel R (Daniel)" Subject: Re: Instance ID for virtual interface To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Toshiaki, I can add this. -Dan > -----Original Message----- > From: Toshiaki Takada [mailto:toshiaki@IPINFUSION.COM] > Sent: Friday, January 03, 2003 9:43 PM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Instance ID for virtual interface > > > Hi, > > I have one question. > > OSPFv3 packet header includes 1 octet "Instance ID" so that > it allows running multiple instances on a single link. > > I thought "Instance ID" for Virtual interfaces could be > configured as well. I looked through OSPFv3 MIB draft, > however "ospfv3VirtIfTable" table doesn't have Instance ID > object in the entry. > > My question is, should we have "ospfv3VirtIfInstId" object > like "ospfv3IfTable", or isn't it allowed to configure > instance ID over virtual link? > > -- Toshiaki Takada > From owner-ospf@DISCUSS.MICROSOFT.COM Mon Jan 6 20:07:52 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20660 for ; Mon, 6 Jan 2003 20:07:52 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.0086A01C@cherry.ease.lsoft.com>; Mon, 6 Jan 2003 20:11:06 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 549348 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 6 Jan 2003 20:11:05 -0500 Received: from 65.223.109.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 6 Jan 2003 20:11:05 -0500 Received: from toro ([127.0.0.1] helo=toro. ident=takada) by toro with esmtp (Exim 3.35 #1 (Debian)) id 18ViCP-0000fw-00 for ; Mon, 06 Jan 2003 17:06:33 -0800 References: User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/21.2 (i686-pc-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Message-ID: <87ptr9ydie.wl@toro.zebra.org> Date: Mon, 6 Jan 2003 17:06:33 -0800 Reply-To: Mailing List Sender: Mailing List From: Toshiaki Takada Organization: IP Infusion, Inc. Subject: Re: Instance ID for virtual interface To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Precedence: list Dan/Vishwas, Thanks for clarification. BTW, there is another question. OSPFv3 supports handling for unknown type of LSAs, but in the draft of OSPFv3 MIB, ospfv3AsLsdbType, ospfv3AreaLsdbType and ospfv3LinkLsdbType seems to accept only known type of LSAs. Is my understanding wrong? Thanks, -- Toshiaki Takada At Mon, 6 Jan 2003 14:57:56 -0500, Joyal, Daniel R (Daniel) wrote: > > Hi Toshiaki, > > I can add this. > > -Dan > > > -----Original Message----- > > From: Toshiaki Takada [mailto:toshiaki@IPINFUSION.COM] > > Sent: Friday, January 03, 2003 9:43 PM > > To: OSPF@DISCUSS.MICROSOFT.COM > > Subject: Instance ID for virtual interface > > > > > > Hi, > > > > I have one question. > > > > OSPFv3 packet header includes 1 octet "Instance ID" so that > > it allows running multiple instances on a single link. > > > > I thought "Instance ID" for Virtual interfaces could be > > configured as well. I looked through OSPFv3 MIB draft, > > however "ospfv3VirtIfTable" table doesn't have Instance ID > > object in the entry. > > > > My question is, should we have "ospfv3VirtIfInstId" object > > like "ospfv3IfTable", or isn't it allowed to configure > > instance ID over virtual link? > > > > -- Toshiaki Takada > > > From owner-ospf@DISCUSS.MICROSOFT.COM Tue Jan 7 01:38:36 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24968 for ; Tue, 7 Jan 2003 01:38:36 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.0086AB45@cherry.ease.lsoft.com>; Tue, 7 Jan 2003 1:41:49 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 550614 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 7 Jan 2003 01:41:49 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 7 Jan 2003 01:41:49 -0500 Received: from redback.com (login005.redback.com [155.53.12.60]) by prattle.redback.com (Postfix) with ESMTP id 005853C7E20 for ; Mon, 6 Jan 2003 22:41:47 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <87ptr9ydie.wl@toro.zebra.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E1A7796.7020005@redback.com> Date: Tue, 7 Jan 2003 01:45:42 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Instance ID for virtual interface To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Toshiaki Takada wrote: > Dan/Vishwas, > > Thanks for clarification. > > BTW, there is another question. OSPFv3 supports handling > for unknown type of LSAs, but in the draft of OSPFv3 MIB, > ospfv3AsLsdbType, ospfv3AreaLsdbType and ospfv3LinkLsdbType > seems to accept only known type of LSAs. Hello Takada-san, This is a reflection of the fact that an LSA is maintained at its respective flooding scope (AS, Area, or Link). For example, ospfv3AsLsdbType is simply a MIB variable corresponding to the LSA type for LSAs maintained in the AS level Link State Database (LSDB). Thanks, Acee > > Is my understanding wrong? > > Thanks, > > -- Toshiaki Takada > > At Mon, 6 Jan 2003 14:57:56 -0500, > Joyal, Daniel R (Daniel) wrote: > >>Hi Toshiaki, >> >> I can add this. >> >>-Dan >> >> >>>-----Original Message----- >>>From: Toshiaki Takada [mailto:toshiaki@IPINFUSION.COM] >>>Sent: Friday, January 03, 2003 9:43 PM >>>To: OSPF@DISCUSS.MICROSOFT.COM >>>Subject: Instance ID for virtual interface >>> >>> >>>Hi, >>> >>>I have one question. >>> >>>OSPFv3 packet header includes 1 octet "Instance ID" so that >>>it allows running multiple instances on a single link. >>> >>>I thought "Instance ID" for Virtual interfaces could be >>>configured as well. I looked through OSPFv3 MIB draft, >>>however "ospfv3VirtIfTable" table doesn't have Instance ID >>>object in the entry. >>> >>>My question is, should we have "ospfv3VirtIfInstId" object >>>like "ospfv3IfTable", or isn't it allowed to configure >>>instance ID over virtual link? >>> >>>-- Toshiaki Takada >>> >> > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Tue Jan 7 03:45:01 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07152 for ; Tue, 7 Jan 2003 03:45:01 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.0086AD26@cherry.ease.lsoft.com>; Tue, 7 Jan 2003 3:48:13 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 551054 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 7 Jan 2003 03:48:13 -0500 Received: from 147.28.0.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 7 Jan 2003 03:48:13 -0500 Received: from psg.com ([147.28.0.62] helo=127.0.0.1 ident=zinin) by psg.com with esmtp (Exim 3.36 #2) id 18VpP3-000MMv-00; Tue, 07 Jan 2003 00:48:05 -0800 X-Mailer: The Bat! (v1.51) Personal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <1532748802.20030107004731@psg.com> Date: Tue, 7 Jan 2003 00:47:31 -0800 Reply-To: Mailing List Sender: Mailing List From: Alex Zinin Subject: Re: Last Call: Traffic Engineering Extensions to OSPF Version 2 to Proposed Standard Comments: To: ietf@ietf.org Comments: cc: iesg@ietf.org, Pyda Srisuresh , Kireeti Kompella , Rohit Dube , acee@redback.com To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Let me try to summarize this discussion. Part of the discussion was on draft-katz-yeung vs draft-srisuesh-ospf-te. Based on the following note from Suresh-- > Make no mistake. The comments I sent to the IETF were solely > in response to the IETF last call on the katz-yeung draft; not > in comparison with any specific draft. --I will ignore the arguments related to this comparison. Further comments in this e-mail are based on the text of Suresh'es original message to the IESG: > The draft is a solution to providing TE within an OSPF area. This does not seem to be an argumentive statement. In fact, the draft is supposed to do exactly this. Nothing's wrong here. > The draft has serious scalability limitations in > extending this to inter-area and mixed networks (with TE and > non-TE nodes). Because a) inter-area TE is a non-goal for this draft, and b) the inter-area TE topic is still in the exploration stage, the draft is not required (nor should it be assumed) to deal with inter-area TE scenarios. Hence, I do not believe that inter-area TE properties should be considered when deciding whether the draft should be published as an RFC or not. Kireeti suggested adding the following text to further clarify the scope of the document: "This document purposely does not say how the mechanisms described here can be used for traffic engineering across multiple OSPF areas; that task is left to future documents." Which I think is a fine idea. Wrt the mixed network scenarios, there doesn't appear to be consensus that behavior of the mechanism that the WG came up with and described in draft-katz-yueng is incorrect or dangerous for the network. On the contrary, my knowledge of the deployment experience suggests that the mechanism is adequate. > Please see my comments below. I would not > recommend using this draft as the basis for building further > TE-extensions to inter-area and mixed networks. Design of the mechanisms for TE in inter-area scenarios is work in progress and subject to the IETF consensus rules. Suresh is welcome to participate in this process. > The draft apparently evolved over time with no requirements > document to guide it. The vendors and implementors behind the > draft may have been guided by different set of requirements > and motivations, such as having some working code. Unfortunately, > this ad-hoc approach has a cost. Any new requirements are having > to be met in a reactive mode and having to be provided as fixes > on top of this "working" code. This is not right and doesnt bode > well for the future of the protocol. As Kireeti mentioned, RFC2702 describes some requirements for MPLS TE. Suresh argued though that it does not describe the requirements for the IGP extensions that would satisfy the MPLS TE requirements. I would like to note, however, that this document has been in the WG for a very long time, passed the WG last call, and there is a consensus that the described mechanism is adequate for the intra-area TE task. > Below are my specific comments on the draft. > > 1. The draft basically describes link TLVs for area-wide > flooding. OSPF is an AS-wide IGP, not just area-wide. > > So, I would suggest renaming the draft as "TE extensions > to an OSPFv2 area", instead of the current title, > "TE extensions to OSPFV2". As Kireeti replied, the abstract already spells this out. Though I do not believe this is a must, spelling this out in the title would also be fine. I'd leave this up to the authors of the document. > Large OSPF networks with multiple areas will not > run this protocol. See above for the multi-area related discussion. > 2. It is confusing to refer an opaque LSA with with a > specific sub-type as "TE LSA". It makes it sound like a > stand-alone OSPF LSA with a distinct LSA type - which > is is not. OSPF LSAs define the flooding scope. TE LSA > does not. > > One suggestion would be to refer Opaque LSAs with specific > sub-type 1 as "TE-type Opaque LSA". I believe that this is a question of editorial preferences. Changing this terminology wouldn't substantially increase clarity or readability of the document. Leaving this up to the authors. > 3. The limitations section (section 1.2) should mention the > following limiations with a mixed network containing TE > and non-TE nodes. > > 1. When a network area is constituted of TE and > native-nodes (supporting IP-only links), the opaque > LSAs will flood all nodes in the area, thereby > disrupting native OSPF nodes. > > As As a general rule, a TE network is likely to generate > significantly more control traffic than a native OSPF > network. The excess traffic is almost directly proportional > to the rate at which TE circuits are set up and torn down > within the TE network. > > The more frequent and wider the flooding frequency, > the larger the number of retransmissions and Acks. > It is undesirable to flood non-TE nodes with TE TLVs. Kireeti replied: > You're right, however, that if non-TE-capable nodes are present in the > network, they will have to flood the LSAs carrying TE information as > well. However, this is a natural characteristic of OSPF flooding and > Opaque LSA mechanism not changed by the TE extensions, hence does not > need to be explicitly explained. Suresh: > Yes. The draft uses Opaque LSA to propogate TE metrics. > Naturally, all the limitations of the opaque LSA will limit > the TE extensions. The consensus within the WG was to use Opaque LSAs to distribute TE information and not change the underlying flooding mechanisms that are critical for the protocol to operate correctly. Given this, I will agree with Kireeti that the draft does not have to spell out what is already natural to the protocol and is not changed. Mentioning this will do no harm, however. I'd leave this up to the authors as well. > 2. A link cannot be reserved for TE-only use. All links > must be subjectable to best-effort IP traffic first, > before any of the links are permitted to carry TE traffic. > > In a mixed network, an OSPF router supporting TE-links > and native IP-links could potentially select a TE link > to be its least cost link and inundate the link with > best-effort IP traffic, thereby rendering the link > unusable for TE purposes. Kireeti suggested that there are at least two ways to exclude a link from the regular IP topology--1) discourage usage of a given link by announcing the maximum possible link cost in the regular OSPF LSAs, and 2) not announce a link in regular LSAs at all. Suresh pointed out that the first method does not completely exclude a link from the regular topology (indeed, when no alternative path is available, such a link will still be used.) Though these mechanisms are not perfect, there does not appear to be consensus that they are inadequate. To summarize, I would like to thank Suresh for his comments and say that though there are a couple of places where the document could benefit from a clarification, no show-stoppers have been identified, and the draft should go forward. What I would also like to emphasize is that not only there was an overwhelming consensus on the draft in the OSPF WG where it was produced (as well as in the GMPLS community that extended the mechanism to support optical networks), but also the described mechanism has been implemented by several router vendors, and deployed in a number of SP networks. Regards. Alex From owner-ospf@DISCUSS.MICROSOFT.COM Tue Jan 7 03:57:40 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07445 for ; Tue, 7 Jan 2003 03:57:39 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.0086AE5E@cherry.ease.lsoft.com>; Tue, 7 Jan 2003 4:00:52 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 551077 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 7 Jan 2003 04:00:51 -0500 Received: from 192.11.226.163 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 7 Jan 2003 03:50:51 -0500 Received: from ii0015exch002u.wins.lucent.com (h135-254-246-205.lucent.com [135.254.246.205]) by hoemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h078onW06699 for ; Tue, 7 Jan 2003 03:50:49 -0500 (EST) Received: by II0015EXCH002U with Internet Mail Service (5.5.2653.19) id ; Tue, 7 Jan 2003 14:20:47 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <6733C768256DEC42A72BAFEFA9CF06D2B88290@II0015EXCH002U> Date: Tue, 7 Jan 2003 14:20:45 +0530 Reply-To: Mailing List Sender: Mailing List From: "Ramalingam, Swaminathan (Swaminathan)" Subject: Re: Instance ID for virtual interface To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list hey vishwas, how r u ? .. I am not able to subscribe to ISIS mailing list ... Any problem in the list ??? swami -----Original Message----- From: Manral, Vishwas [mailto:VishwasM@NETPLANE.COM] Sent: Monday, January 06, 2003 10:18 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: Instance ID for virtual interface Hi Takada-san, Though Dan will clarify further, I think we should allow configuring the "Instance Id" for a virtual link too. Thanks, Vishwas -----Original Message----- From: Toshiaki Takada [mailto:toshiaki@IPINFUSION.COM] Sent: Saturday, January 04, 2003 8:13 AM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Instance ID for virtual interface Hi, I have one question. OSPFv3 packet header includes 1 octet "Instance ID" so that it allows running multiple instances on a single link. I thought "Instance ID" for Virtual interfaces could be configured as well. I looked through OSPFv3 MIB draft, however "ospfv3VirtIfTable" table doesn't have Instance ID object in the entry. My question is, should we have "ospfv3VirtIfInstId" object like "ospfv3IfTable", or isn't it allowed to configure instance ID over virtual link? -- Toshiaki Takada From owner-ospf@DISCUSS.MICROSOFT.COM Wed Jan 8 08:58:26 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19914 for ; Wed, 8 Jan 2003 08:58:26 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.0086DF51@cherry.ease.lsoft.com>; Wed, 8 Jan 2003 9:01:15 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 557615 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 8 Jan 2003 09:01:15 -0500 Received: from 203.199.83.26 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 8 Jan 2003 09:01:14 -0500 Received: (qmail 12913 invoked by uid 510); 8 Jan 2003 13:55:45 -0000 Received: from unknown (203.197.138.201) by rediffmail.com via HTTP; 08 jan 2003 13:55:45 -0000 MIME-Version: 1.0 Content-type: text/plain; format=flowed Content-Disposition: inline Message-ID: <20030108135545.12912.qmail@webmail16.rediffmail.com> Date: Wed, 8 Jan 2003 13:55:45 -0000 Reply-To: Mailing List Sender: Mailing List From: Krishna Rao Subject: Ospf Host Entry To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi, i need some inputs on Host Entry. earlier ospf mib rfc 1850 have HostAreaId as read only variable but in the latest draft it is Read-Create. what is the reason for this change ? can i configure a Host Entry Like this i have two interfaces on first interface ip and ospf is both enabled and ip address is 20.0.0.10 on second interface ip is enabled but ospf is not enabled and Ip address for interface is 30.0.0.10 now i want to add a host entry with Host Ip Addr 30.0.0.10 is this configuration is valid or not ? if yes and say we are supporting older mib ( rfc 1850 ) which area does host belongs to. Thanks Krishna From owner-ospf@DISCUSS.MICROSOFT.COM Thu Jan 9 09:19:42 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10584 for ; Thu, 9 Jan 2003 09:19:42 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.00870945@cherry.ease.lsoft.com>; Thu, 9 Jan 2003 9:22:57 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 561919 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 9 Jan 2003 09:22:57 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 9 Jan 2003 09:22:57 -0500 Received: from redback.com (login003.redback.com [155.53.12.55]) by prattle.redback.com (Postfix) with ESMTP id 325A3313114 for ; Thu, 9 Jan 2003 06:22:56 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E1D868C.3050303@redback.com> Date: Thu, 9 Jan 2003 09:26:20 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: 56th IETF OSPF WG Meeting To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit We will be meeting in San Francisco. Please E-mail Rohit and I potential agenda items. Thanks, --- Acee and Rohit From owner-ospf@DISCUSS.MICROSOFT.COM Thu Jan 9 17:59:29 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29202 for ; Thu, 9 Jan 2003 17:59:29 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.00871C26@cherry.ease.lsoft.com>; Thu, 9 Jan 2003 18:02:44 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 563820 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 9 Jan 2003 18:02:43 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 9 Jan 2003 18:02:43 -0500 Received: from redback.com (login003.redback.com [155.53.12.55]) by prattle.redback.com (Postfix) with ESMTP id 4D368F6FE6 for ; Thu, 9 Jan 2003 15:02:42 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <3E009AFA.9010208@redback.com> <87hed8vus6.wl@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E1E0059.5000806@redback.com> Date: Thu, 9 Jan 2003 18:06:01 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: OSPFv3 Applications Support To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Kunihiro Ishiguro wrote: >>At the 55th IETF WG meeting, there were two proposals for >>supporting additional OSPF applications. There was quite >>a lively discussion of the relative merits of each and >>we decided that it would be best to discuss it further on >>the OSPF WG list. Heretofore, there hasn't been any further >>discussion so I figure it is time to get the ball rolling (or >>in this case, the E-mails flying). >> >> - OSPFv2 Opaque LSAs in OSPFv3 >> http://www.ietf.org/internet-drafts/draft-kompella-ospf-opaquev2-00.txt >> >> - Traffic Engineering Extensions to OSPF version 3 >> http://www.ietf.org/internet-drafts/draft-ishiguro-ospf-ospfv3-traffic-01.txt >> >>The first defines the transformations necessary to map OSPFv2 >>opaque LSAs to OSPFv3. The second defines how to map the most >>widely implemented and deployed OSPFv2 opaque to OSPFv3 using >>new LSA types. > > > Well, besides I wrote a draft for OSPFv3 TE, I support defining a new > LS type for new application. OSPFv3 already has clean design and very > flexible architecture for new application. [Speaking as WG member] I have to agree with you here. I can't see the point of adding another layer of multiplexing for these types in OSPFv3. In OSPFv2, the opaque type was necessary since unknown types weren't handled. From an applications standpoint, it is much more likely that one is going to want to do something (whether it be process or view) all the LSAs associated with a given type than all opaque LSAs. The only additional cost that I see is that when an opaque type is requested from IANA for OSPFv2, an OSPFv3 LSA type function code must also be requested. --- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Sun Jan 12 05:22:08 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08162 for ; Sun, 12 Jan 2003 05:22:07 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.0087DF65@cherry.ease.lsoft.com>; 12 Jan 2003 5:25:24 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 579026 for OSPF@DISCUSS.MICROSOFT.COM; Sun, 12 Jan 2003 05:25:24 -0500 Received: from 12.27.183.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 12 Jan 2003 05:25:24 -0500 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <4B0HTBCQ>; Sun, 12 Jan 2003 05:25:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Sun, 12 Jan 2003 05:27:25 -0500 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: How could OPSFv3 support IPv4 ? To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Michael, Just one comments regarding non-v4AF supporting routers. I think a similar problem exists for Opaque support too in OSPFv2, because it could happen that the DR supported may not have Opaque support. I think a simple solution to these kinds of problems is http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0205&L=ospf&T=0&F=&S=& P=7884 http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0206&L=OSPF&P=R3746&I= -3 Let me know if you agree. Thanks, Vishwas -----Original Message----- From: Michael J Barnes [mailto:mjbarnes@CISCO.COM] Sent: Friday, January 03, 2003 11:05 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: How could OPSFv3 support IPv4 ? Hello Vishwas and everyone, I'm thinking along these lines too. If nobody else is, I'm prepared to start writing a draft document for supporting IPv4 addresses in OSPFv3. It seems that there is enough interest in this capability to warrant it. These are the points I have, taken from previous e-mails and thoughts of my own: - Create IPv4 Address Family versions of the Link, Intra-Area-Prefix, Inter-Area-Prefix, and AS-External LSAs. These LSAs would be adaptations of the current OSPFv3 LSAs. Unless otherwise specified, these LSAs will be treated in the same manner as their IPv6 counterparts. - Whether or not the U-bit is set in IPv4 AF LSAs should be user configurable, but defaulting to set. - Have a v4-bit in the Options field, indicating whether or not the router forwards IPv4 packets. - If all router LSAs have the v4 bit set, then a single SPF calculation can be done. Otherwise there must be a separate v4 SPF calculation. An implementation can always do two SPF calculations. - Whether or not an ABR originates IPv4 AF Inter-Area-Summary LSAs should be user configurable. - If the v6-bit is set for the router, then any interface over which an adjacency can be formed must forward IPv6 packets. Interfaces that forward IPv4 packets but not IPv6 packets will, in general, be treated like connections to stub networks. The two issues I'm most concerned about are 1) how to handle multi-access networks with some non-v4AF capable routers, and 2) routers with both the v6-bit and v4-bit set, but which have some interfaces on a transit links which are not able to forward IPv4 packets. Routers on a broadcast link which do not support IPv4 AF should have their router priority set to 0 so that they do not become the DR. However, we need to consider how the case of the DR not v4AF capable. Some ideas: 1 - The v4AF capable routers on the link select a proxy DR which will originate the v4 Intra-Area-Prefix LSA for the link. Special rules are needed for some cases, non-full mesh NBMA networks for example. In those cases the v4AF capable routers will not originate v4 Link LSAs for the network. (Thus the v4 bit will not be set in the Network LSA, and the network will not function as a transit network for IPv4.) 2 - Each v4AF capable router could originate a v4 Intra-Area-Prefix LSA associated with its Router LSA, advertising just its own v4 prefixes for the link. Some special rules would also be needed for this solution. 3 - Require the v4AF capable routers to automatically raise their priorities by the amount of the highest priority of the non v4AF capable routers. I also have a few ideas about routers which have the v6-bit and v4-bit set but are able to forward IPv4 packets on only some of the interfaces which can forward IPv6 packets. (Excepting interfaces connected to stub networks.) 1 - Define one of the bits in the unused byte between the Type and Metric fields as a v4-bit. If this bit is not set the interface would not be considered during the IPv4 SPF calculation. This bit will only be set if there is a v4AF capable neighor on this link. 2 - The interface must be either 2-WAY or FULL with at least one v4AF capable neighbor, and must be able to forward IPv4 packets on that interface. Otherwise the interface will be treated as if it were connected to a stub network and it will not be listed in the Router LSA. 3 - If some, but not all, interfaces have IPv4 enabled then originate two Router LSAs, one with the v6-bit set and the other with the v4-bit set. Each Router LSA would then describe the interfaces which are capable of forwarding their corresponding IP packets. I look forward to further discussion. Regards, Michael > -----Original Message----- > From: Manral, Vishwas [mailto:VishwasM@NETPLANE.COM] > Sent: Thursday, December 12, 2002 10:44 AM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Re: How could OPSFv3 support IPv4 ? > > Hi Vincent, > > I think importing v2 LSA's directly would not be a good idea in this case, > as most of the information other than the IPv4 addresses are already there > in OSPFv3 LSA's. Importing it would make it compulsary for OSPFv3 to > understand OSPFv2 LSA types, besides the entire SPF processing(as well as > LSA generation), would have to change to make use of information contained > in OSPFv2 LSA's. > > Using just the new OSPFv3 LSA's with equivalents for the IPv6 address > containing LSA's, would make the job a lot easier, and we could infact do > the SPF irrespective of protocol, and IPv4/IPv6 address nodes would be added > as stubs on the tree. > > Thanks, > Vishwas > > -----Original Message----- > From: Vincent Jardin [mailto:jardin@6WIND.COM] > Sent: Thursday, December 12, 2002 1:10 AM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Re: How could OPSFv3 support IPv4 ? > > Hi Vishwas, > > If we just have some new LSA types instead of the IPv4 mapped IPv6 > address, would it be enough to import the OSPFv2 LSA's within OSPFv3 ? > > Moreover, it could use the scope feature of OSPFv3. > > Vincent > > On Wed, 11 Dec 2002, Acee Lindem wrote: > > > Manral, Vishwas wrote: > > > Hi Yasu, > > > > > > I think you missed "Link-LSA" equivalents. I think they would be > required > > > too !!! > > > > Yup. I think these would be needed too. Also, if we were serious about > this > > I don't think using the IPv4 mapped IPv6 address is the best way to go. It > > would be better to have new LSA types for for IPv4 or with an AF and > generic > > address. > > > > > > > > Thanks, > > > Vishwas > > > > > > -----Original Message----- > > > From: Yasuhiro Ohara [mailto:yasu@SFC.WIDE.AD.JP] > > > Sent: Wednesday, December 11, 2002 7:48 PM > > > To: OSPF@DISCUSS.MICROSOFT.COM > > > Subject: Re: How could OPSFv3 support IPv4 ? > > > > > > > > > > > >>I am wondering how OSPFv3 could support IPv4. > > >> > > >>According to the RFC2740, the 24-bit OSPFv3 options field describes the > > >>router capabilities. For example, the R-bit and the V6-bit are used in > > >>order to announce IPv6 forwarding capabilities. However, what's happened > > >>if this V6-bit is clear ? > > > > > > > > > RFC2740's section 2.7 gives the exact answer: > > > > > > V6-bit specializes the R-bit; if the V6-bit is clear an OSPF > > > speaker can participate in OSPF topology distribution without > > > being used to forward IPv6 datagrams. If the R-bit is set and the > > > V6-bit is clear, IPv6 datagrams are not forwarded but diagrams > > > belonging to another protocol family may be forwarded. > > > > > > In routers do not support other protocol family other than IPv6, > > > the router having V6-bit off should be treated as a non-working router > > > from the rest of the network. > > > > > > > > >>If there would be a V4-bit in order to announce the IPv4 capabilities, > > >>how could OSPFv3 be extended in order to support IPv4 like Integrated > > >>ISIS ? > > > > > > > > > You'll need only to define IPv4 version of Intra-Area-Prefix-LSA, > > > Inter-Area-Prefix-LSA, AS-External-LSA. Using IPv6 address holding > > > embedded IPv4 address is another option. I guess IPv4-mapped will be > > > the right choice semantically in that case, but it may not be > > > accepted as I saw someone states "IPv4-mapped address should not > > > appear on the wire" somewhere. I believe it means as IP source or > > > destination, though. > > > > > > regards, > > > yasu > > > > Acee > > From owner-ospf@DISCUSS.MICROSOFT.COM Sun Jan 12 13:05:42 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12884 for ; Sun, 12 Jan 2003 13:05:42 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.0087F809@cherry.ease.lsoft.com>; 12 Jan 2003 13:08:59 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 581215 for OSPF@DISCUSS.MICROSOFT.COM; Sun, 12 Jan 2003 13:08:59 -0500 Received: from 171.70.145.30 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 12 Jan 2003 13:08:59 -0500 Received: from mira-sjc5-f.cisco.com (IDENT:mirapoint@mira-sjc5-f.cisco.com [171.71.163.13]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id h0CI95fm025942 for ; Sun, 12 Jan 2003 10:09:05 -0800 (PST) Received: from cisco.com (sjc-vpn1-772.cisco.com [10.21.99.4]) by mira-sjc5-f.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ACB34168; Sun, 12 Jan 2003 10:14:40 -0800 (PST) X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-19.7.x i686) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3E21AF3D.18F9F0B@cisco.com> Date: Sun, 12 Jan 2003 10:09:01 -0800 Reply-To: Mailing List Sender: Mailing List From: Michael J Barnes Subject: Re: How could OPSFv3 support IPv4 ? To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hello Vishwas, Yes, this is a good idea, and I'll add it to my notes to include in the draft (which I'm going to start on this morning). However, if I'm not mistaken this method does rely on the v4AF capable router to be able to win the DR election. I think we should specify that behavior, but we also need to consider what should happen if a v4AF capable router can not win the election. So I propose we do this: 1) If the DR is not v4AF capable, and the v4AF capable router recognizes that it would become the DR after a new election, then it will declare itself first to be BDR, and then after it has formed adjacencies with the other routers on the network, it will declare itself to be DR. If the v4AF capable router can beat the DR but not the BDR then it will skip the BDR steps. 2) If the v4AF capable router can not win the DR election, then the v4AF capable routers will Thanks Michael "Manral, Vishwas" wrote: > > Hi Michael, > > Just one comments regarding non-v4AF supporting routers. I think a similar > problem exists for Opaque support too in OSPFv2, because it could happen > that the DR supported may not have Opaque support. > > I think a simple solution to these kinds of problems is > http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0205&L=ospf&T=0&F=&S=& > P=7884 > > http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0206&L=OSPF&P=R3746&I= > -3 > > Let me know if you agree. > > Thanks, > Vishwas > > -----Original Message----- > From: Michael J Barnes [mailto:mjbarnes@CISCO.COM] > Sent: Friday, January 03, 2003 11:05 PM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Re: How could OPSFv3 support IPv4 ? > > Hello Vishwas and everyone, > > I'm thinking along these lines too. If nobody else is, I'm prepared to > start writing a draft document for supporting IPv4 addresses in OSPFv3. It > seems that there is enough interest in this capability to warrant it. > > These are the points I have, taken from previous e-mails and thoughts of > my own: > > - Create IPv4 Address Family versions of the Link, Intra-Area-Prefix, > Inter-Area-Prefix, and AS-External LSAs. These LSAs would be adaptations > of the current OSPFv3 LSAs. Unless otherwise specified, these LSAs will > be treated in the same manner as their IPv6 counterparts. > - Whether or not the U-bit is set in IPv4 AF LSAs should be user > configurable, but defaulting to set. > - Have a v4-bit in the Options field, indicating whether or not the > router forwards IPv4 packets. > - If all router LSAs have the v4 bit set, then a single SPF calculation > can be done. Otherwise there must be a separate v4 SPF calculation. > An implementation can always do two SPF calculations. > - Whether or not an ABR originates IPv4 AF Inter-Area-Summary LSAs should > be user configurable. > - If the v6-bit is set for the router, then any interface over which an > adjacency can be formed must forward IPv6 packets. Interfaces that > forward IPv4 packets but not IPv6 packets will, in general, be treated > like connections to stub networks. > > The two issues I'm most concerned about are 1) how to handle multi-access > networks with some non-v4AF capable routers, and 2) routers with both the > v6-bit and v4-bit set, but which have some interfaces on a transit links > which are not able to forward IPv4 packets. > > Routers on a broadcast link which do not support IPv4 AF should have their > router priority set to 0 so that they do not become the DR. However, we > need to consider how the case of the DR not v4AF capable. > > Some ideas: > > 1 - The v4AF capable routers on the link select a proxy DR which will > originate the v4 Intra-Area-Prefix LSA for the link. > > Special rules are needed for some cases, non-full mesh NBMA networks > for example. In those cases the v4AF capable routers will not > originate v4 Link LSAs for the network. (Thus the v4 bit will not be > set in the Network LSA, and the network will not function as a > transit network for IPv4.) > > 2 - Each v4AF capable router could originate a v4 Intra-Area-Prefix LSA > associated with its Router LSA, advertising just its own v4 > prefixes for the link. > > Some special rules would also be needed for this solution. > > 3 - Require the v4AF capable routers to automatically raise their > priorities by the amount of the highest priority of the non v4AF > capable routers. > > I also have a few ideas about routers which have the v6-bit and v4-bit set > but are able to forward IPv4 packets on only some of the interfaces which > can forward IPv6 packets. (Excepting interfaces connected to stub > networks.) > > 1 - Define one of the bits in the unused byte between the Type and Metric > fields as a v4-bit. If this bit is not set the interface would > not be considered during the IPv4 SPF calculation. This bit will > only be set if there is a v4AF capable neighor on this link. > > 2 - The interface must be either 2-WAY or FULL with at least one v4AF > capable neighbor, and must be able to forward IPv4 packets on that > interface. Otherwise the interface will be treated as if it were > connected to a stub network and it will not be listed in the > Router LSA. > > 3 - If some, but not all, interfaces have IPv4 enabled then originate > two Router LSAs, one with the v6-bit set and the other with the > v4-bit set. Each Router LSA would then describe the interfaces which > are capable of forwarding their corresponding IP packets. > > I look forward to further discussion. > > Regards, > Michael > > > -----Original Message----- > > From: Manral, Vishwas [mailto:VishwasM@NETPLANE.COM] > > Sent: Thursday, December 12, 2002 10:44 AM > > To: OSPF@DISCUSS.MICROSOFT.COM > > Subject: Re: How could OPSFv3 support IPv4 ? > > > > Hi Vincent, > > > > I think importing v2 LSA's directly would not be a good idea in this case, > > as most of the information other than the IPv4 addresses are already there > > in OSPFv3 LSA's. Importing it would make it compulsary for OSPFv3 to > > understand OSPFv2 LSA types, besides the entire SPF processing(as well as > > LSA generation), would have to change to make use of information contained > > in OSPFv2 LSA's. > > > > Using just the new OSPFv3 LSA's with equivalents for the IPv6 address > > containing LSA's, would make the job a lot easier, and we could infact do > > the SPF irrespective of protocol, and IPv4/IPv6 address nodes would be > added > > as stubs on the tree. > > > > Thanks, > > Vishwas > > > > -----Original Message----- > > From: Vincent Jardin [mailto:jardin@6WIND.COM] > > Sent: Thursday, December 12, 2002 1:10 AM > > To: OSPF@DISCUSS.MICROSOFT.COM > > Subject: Re: How could OPSFv3 support IPv4 ? > > > > Hi Vishwas, > > > > If we just have some new LSA types instead of the IPv4 mapped IPv6 > > address, would it be enough to import the OSPFv2 LSA's within OSPFv3 ? > > > > Moreover, it could use the scope feature of OSPFv3. > > > > Vincent > > > > On Wed, 11 Dec 2002, Acee Lindem wrote: > > > > > Manral, Vishwas wrote: > > > > Hi Yasu, > > > > > > > > I think you missed "Link-LSA" equivalents. I think they would be > > required > > > > too !!! > > > > > > Yup. I think these would be needed too. Also, if we were serious about > > this > > > I don't think using the IPv4 mapped IPv6 address is the best way to go. > It > > > would be better to have new LSA types for for IPv4 or with an AF and > > generic > > > address. > > > > > > > > > > > Thanks, > > > > Vishwas > > > > > > > > -----Original Message----- > > > > From: Yasuhiro Ohara [mailto:yasu@SFC.WIDE.AD.JP] > > > > Sent: Wednesday, December 11, 2002 7:48 PM > > > > To: OSPF@DISCUSS.MICROSOFT.COM > > > > Subject: Re: How could OPSFv3 support IPv4 ? > > > > > > > > > > > > > > > >>I am wondering how OSPFv3 could support IPv4. > > > >> > > > >>According to the RFC2740, the 24-bit OSPFv3 options field describes > the > > > >>router capabilities. For example, the R-bit and the V6-bit are used in > > > >>order to announce IPv6 forwarding capabilities. However, what's > happened > > > >>if this V6-bit is clear ? > > > > > > > > > > > > RFC2740's section 2.7 gives the exact answer: > > > > > > > > V6-bit specializes the R-bit; if the V6-bit is clear an OSPF > > > > speaker can participate in OSPF topology distribution without > > > > being used to forward IPv6 datagrams. If the R-bit is set and > the > > > > V6-bit is clear, IPv6 datagrams are not forwarded but diagrams > > > > belonging to another protocol family may be forwarded. > > > > > > > > In routers do not support other protocol family other than IPv6, > > > > the router having V6-bit off should be treated as a non-working router > > > > from the rest of the network. > > > > > > > > > > > >>If there would be a V4-bit in order to announce the IPv4 capabilities, > > > >>how could OSPFv3 be extended in order to support IPv4 like Integrated > > > >>ISIS ? > > > > > > > > > > > > You'll need only to define IPv4 version of Intra-Area-Prefix-LSA, > > > > Inter-Area-Prefix-LSA, AS-External-LSA. Using IPv6 address holding > > > > embedded IPv4 address is another option. I guess IPv4-mapped will be > > > > the right choice semantically in that case, but it may not be > > > > accepted as I saw someone states "IPv4-mapped address should not > > > > appear on the wire" somewhere. I believe it means as IP source or > > > > destination, though. > > > > > > > > regards, > > > > yasu > > > > > > Acee > > > -- Michael Barnes Core IP Eng - Routing 408-525-2785 From owner-ospf@DISCUSS.MICROSOFT.COM Mon Jan 13 05:29:09 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07032 for ; Mon, 13 Jan 2003 05:29:09 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00885FF1@cherry.ease.lsoft.com>; Mon, 13 Jan 2003 5:32:26 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 586802 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 13 Jan 2003 05:32:25 -0500 Received: from 12.27.183.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 13 Jan 2003 05:32:25 -0500 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <4B0HTCAL>; Mon, 13 Jan 2003 05:32:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Mon, 13 Jan 2003 05:34:06 -0500 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: How could OPSFv3 support IPv4 ? To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Michael, The case of a guy not winning the DR election does not arise with that method. If we want to make a router a DR the method given is a sureshot way to do it. Besides, the method is independent of the version of OSPF(OSPFv2 or OSPFv3), and can be used for other cases too. I can explain it offline if you want. Thanks, Vishwas -----Original Message----- From: Michael J Barnes [mailto:mjbarnes@CISCO.COM] Sent: Sunday, January 12, 2003 11:39 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: How could OPSFv3 support IPv4 ? Hello Vishwas, Yes, this is a good idea, and I'll add it to my notes to include in the draft (which I'm going to start on this morning). However, if I'm not mistaken this method does rely on the v4AF capable router to be able to win the DR election. I think we should specify that behavior, but we also need to consider what should happen if a v4AF capable router can not win the election. So I propose we do this: 1) If the DR is not v4AF capable, and the v4AF capable router recognizes that it would become the DR after a new election, then it will declare itself first to be BDR, and then after it has formed adjacencies with the other routers on the network, it will declare itself to be DR. If the v4AF capable router can beat the DR but not the BDR then it will skip the BDR steps. 2) If the v4AF capable router can not win the DR election, then the v4AF capable routers will Thanks Michael "Manral, Vishwas" wrote: > > Hi Michael, > > Just one comments regarding non-v4AF supporting routers. I think a similar > problem exists for Opaque support too in OSPFv2, because it could happen > that the DR supported may not have Opaque support. > > I think a simple solution to these kinds of problems is > http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0205&L=ospf&T=0&F=&S=& > P=7884 > > http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0206&L=OSPF&P=R3746&I= > -3 > > Let me know if you agree. > > Thanks, > Vishwas > > -----Original Message----- > From: Michael J Barnes [mailto:mjbarnes@CISCO.COM] > Sent: Friday, January 03, 2003 11:05 PM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Re: How could OPSFv3 support IPv4 ? > > Hello Vishwas and everyone, > > I'm thinking along these lines too. If nobody else is, I'm prepared to > start writing a draft document for supporting IPv4 addresses in OSPFv3. It > seems that there is enough interest in this capability to warrant it. > > These are the points I have, taken from previous e-mails and thoughts of > my own: > > - Create IPv4 Address Family versions of the Link, Intra-Area-Prefix, > Inter-Area-Prefix, and AS-External LSAs. These LSAs would be adaptations > of the current OSPFv3 LSAs. Unless otherwise specified, these LSAs will > be treated in the same manner as their IPv6 counterparts. > - Whether or not the U-bit is set in IPv4 AF LSAs should be user > configurable, but defaulting to set. > - Have a v4-bit in the Options field, indicating whether or not the > router forwards IPv4 packets. > - If all router LSAs have the v4 bit set, then a single SPF calculation > can be done. Otherwise there must be a separate v4 SPF calculation. > An implementation can always do two SPF calculations. > - Whether or not an ABR originates IPv4 AF Inter-Area-Summary LSAs should > be user configurable. > - If the v6-bit is set for the router, then any interface over which an > adjacency can be formed must forward IPv6 packets. Interfaces that > forward IPv4 packets but not IPv6 packets will, in general, be treated > like connections to stub networks. > > The two issues I'm most concerned about are 1) how to handle multi-access > networks with some non-v4AF capable routers, and 2) routers with both the > v6-bit and v4-bit set, but which have some interfaces on a transit links > which are not able to forward IPv4 packets. > > Routers on a broadcast link which do not support IPv4 AF should have their > router priority set to 0 so that they do not become the DR. However, we > need to consider how the case of the DR not v4AF capable. > > Some ideas: > > 1 - The v4AF capable routers on the link select a proxy DR which will > originate the v4 Intra-Area-Prefix LSA for the link. > > Special rules are needed for some cases, non-full mesh NBMA networks > for example. In those cases the v4AF capable routers will not > originate v4 Link LSAs for the network. (Thus the v4 bit will not be > set in the Network LSA, and the network will not function as a > transit network for IPv4.) > > 2 - Each v4AF capable router could originate a v4 Intra-Area-Prefix LSA > associated with its Router LSA, advertising just its own v4 > prefixes for the link. > > Some special rules would also be needed for this solution. > > 3 - Require the v4AF capable routers to automatically raise their > priorities by the amount of the highest priority of the non v4AF > capable routers. > > I also have a few ideas about routers which have the v6-bit and v4-bit set > but are able to forward IPv4 packets on only some of the interfaces which > can forward IPv6 packets. (Excepting interfaces connected to stub > networks.) > > 1 - Define one of the bits in the unused byte between the Type and Metric > fields as a v4-bit. If this bit is not set the interface would > not be considered during the IPv4 SPF calculation. This bit will > only be set if there is a v4AF capable neighor on this link. > > 2 - The interface must be either 2-WAY or FULL with at least one v4AF > capable neighbor, and must be able to forward IPv4 packets on that > interface. Otherwise the interface will be treated as if it were > connected to a stub network and it will not be listed in the > Router LSA. > > 3 - If some, but not all, interfaces have IPv4 enabled then originate > two Router LSAs, one with the v6-bit set and the other with the > v4-bit set. Each Router LSA would then describe the interfaces which > are capable of forwarding their corresponding IP packets. > > I look forward to further discussion. > > Regards, > Michael > > > -----Original Message----- > > From: Manral, Vishwas [mailto:VishwasM@NETPLANE.COM] > > Sent: Thursday, December 12, 2002 10:44 AM > > To: OSPF@DISCUSS.MICROSOFT.COM > > Subject: Re: How could OPSFv3 support IPv4 ? > > > > Hi Vincent, > > > > I think importing v2 LSA's directly would not be a good idea in this case, > > as most of the information other than the IPv4 addresses are already there > > in OSPFv3 LSA's. Importing it would make it compulsary for OSPFv3 to > > understand OSPFv2 LSA types, besides the entire SPF processing(as well as > > LSA generation), would have to change to make use of information contained > > in OSPFv2 LSA's. > > > > Using just the new OSPFv3 LSA's with equivalents for the IPv6 address > > containing LSA's, would make the job a lot easier, and we could infact do > > the SPF irrespective of protocol, and IPv4/IPv6 address nodes would be > added > > as stubs on the tree. > > > > Thanks, > > Vishwas > > > > -----Original Message----- > > From: Vincent Jardin [mailto:jardin@6WIND.COM] > > Sent: Thursday, December 12, 2002 1:10 AM > > To: OSPF@DISCUSS.MICROSOFT.COM > > Subject: Re: How could OPSFv3 support IPv4 ? > > > > Hi Vishwas, > > > > If we just have some new LSA types instead of the IPv4 mapped IPv6 > > address, would it be enough to import the OSPFv2 LSA's within OSPFv3 ? > > > > Moreover, it could use the scope feature of OSPFv3. > > > > Vincent > > > > On Wed, 11 Dec 2002, Acee Lindem wrote: > > > > > Manral, Vishwas wrote: > > > > Hi Yasu, > > > > > > > > I think you missed "Link-LSA" equivalents. I think they would be > > required > > > > too !!! > > > > > > Yup. I think these would be needed too. Also, if we were serious about > > this > > > I don't think using the IPv4 mapped IPv6 address is the best way to go. > It > > > would be better to have new LSA types for for IPv4 or with an AF and > > generic > > > address. > > > > > > > > > > > Thanks, > > > > Vishwas > > > > > > > > -----Original Message----- > > > > From: Yasuhiro Ohara [mailto:yasu@SFC.WIDE.AD.JP] > > > > Sent: Wednesday, December 11, 2002 7:48 PM > > > > To: OSPF@DISCUSS.MICROSOFT.COM > > > > Subject: Re: How could OPSFv3 support IPv4 ? > > > > > > > > > > > > > > > >>I am wondering how OSPFv3 could support IPv4. > > > >> > > > >>According to the RFC2740, the 24-bit OSPFv3 options field describes > the > > > >>router capabilities. For example, the R-bit and the V6-bit are used in > > > >>order to announce IPv6 forwarding capabilities. However, what's > happened > > > >>if this V6-bit is clear ? > > > > > > > > > > > > RFC2740's section 2.7 gives the exact answer: > > > > > > > > V6-bit specializes the R-bit; if the V6-bit is clear an OSPF > > > > speaker can participate in OSPF topology distribution without > > > > being used to forward IPv6 datagrams. If the R-bit is set and > the > > > > V6-bit is clear, IPv6 datagrams are not forwarded but diagrams > > > > belonging to another protocol family may be forwarded. > > > > > > > > In routers do not support other protocol family other than IPv6, > > > > the router having V6-bit off should be treated as a non-working router > > > > from the rest of the network. > > > > > > > > > > > >>If there would be a V4-bit in order to announce the IPv4 capabilities, > > > >>how could OSPFv3 be extended in order to support IPv4 like Integrated > > > >>ISIS ? > > > > > > > > > > > > You'll need only to define IPv4 version of Intra-Area-Prefix-LSA, > > > > Inter-Area-Prefix-LSA, AS-External-LSA. Using IPv6 address holding > > > > embedded IPv4 address is another option. I guess IPv4-mapped will be > > > > the right choice semantically in that case, but it may not be > > > > accepted as I saw someone states "IPv4-mapped address should not > > > > appear on the wire" somewhere. I believe it means as IP source or > > > > destination, though. > > > > > > > > regards, > > > > yasu > > > > > > Acee > > > From owner-ospf@DISCUSS.MICROSOFT.COM Thu Jan 16 08:17:19 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09504 for ; Thu, 16 Jan 2003 08:17:18 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.00895925@cherry.ease.lsoft.com>; Thu, 16 Jan 2003 8:20:38 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 607019 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 16 Jan 2003 08:20:38 -0500 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 16 Jan 2003 08:10:38 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08967; Thu, 16 Jan 2003 08:07:13 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200301161307.IAA08967@ietf.org> Date: Thu, 16 Jan 2003 08:07:13 -0500 Reply-To: Mailing List Sender: Mailing List Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ospf-hitless-restart-05.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF. Title : Hitless OSPF Restart Author(s) : J. Moy et al. Filename : draft-ietf-ospf-hitless-restart-05.txt Pages : 15 Date : 2003-1-15 This memo documents an enhancement to the OSPF routing protocol, whereby an OSPF router can stay on the forwarding path even as its OSPF software is restarted. This is called 'hitless restart' or 'non-stop forwarding'. A restarting router may not be capable of adjusting its forwarding in a timely manner when the network topology changes. In order to avoid the possible resulting routing loops the procedure in this memo automatically reverts to a normal OSPF restart when such a topology change is detected, or when one or more of the restarting router's neighbors do not support the enhancements in this memo. Proper network operation during a hitless restart makes assumptions upon the operating environment of the restarting router; these assumptions are also documented. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-hitless-restart-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ospf-hitless-restart-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ospf-hitless-restart-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-1-15125736.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ospf-hitless-restart-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ospf-hitless-restart-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-15125736.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@DISCUSS.MICROSOFT.COM Thu Jan 16 10:28:55 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13778 for ; Thu, 16 Jan 2003 10:28:55 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00895C99@cherry.ease.lsoft.com>; Thu, 16 Jan 2003 10:32:16 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 607465 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 16 Jan 2003 10:32:16 -0500 Received: from 169.144.68.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 16 Jan 2003 10:32:16 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA14610 for ; Thu, 16 Jan 2003 10:32:14 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA23558 for ; Thu, 16 Jan 2003 10:32:14 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 16 Jan 2003 10:32:14 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Message-ID: <39469E08BD83D411A3D900204840EC55B864DE@vie-msgusr-01.dc.fore.com> Date: Thu, 16 Jan 2003 10:32:13 -0500 Reply-To: Mailing List Sender: Mailing List From: "Banerjee, Gargi" Subject: Determining which LSA is newer To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi, I had a question regarding section 13.1 (Determining which lsa is newer) in rfc 2328. Bullet 3 in the above section says : Else, if only one of the instances has its LS age field set to MaxAge, the instance of age MaxAge is considered to be more recent. I was wondering why we are specific about exactly one of the lsas being of maxage. What if we receive a maxaged lsa and the current copy in the database maxages at exactly the same time. According to section 13.1 these two lsas will be considered identical (assuming sequence number etc. is the same). However, what could be the possible disadvantage of treating the received maxage lsa as the more current one, replacing the database copy with this lsa and flooding it out to our neighbors. Thanks in advance, Gargi From owner-ospf@DISCUSS.MICROSOFT.COM Thu Jan 16 10:36:57 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14010 for ; Thu, 16 Jan 2003 10:36:57 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.00895DB2@cherry.ease.lsoft.com>; Thu, 16 Jan 2003 10:40:18 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 607503 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 16 Jan 2003 10:40:18 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 16 Jan 2003 10:40:17 -0500 Received: from redback.com (login001.redback.com [155.53.12.18]) by prattle.redback.com (Postfix) with ESMTP id 8313E50E96E for ; Thu, 16 Jan 2003 07:40:16 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <39469E08BD83D411A3D900204840EC55B864DE@vie-msgusr-01.dc.fore.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E26D2D0.2030304@redback.com> Date: Thu, 16 Jan 2003 10:42:08 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Determining which LSA is newer To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Banerjee, Gargi wrote: > Hi, > I had a question regarding section 13.1 (Determining which lsa is newer) in > rfc 2328. > Bullet 3 in the above section says : > > Else, if only one of the instances has its LS age field set > to MaxAge, the instance of age MaxAge is considered to be > more recent. > > I was wondering why we are specific about exactly one of the lsas being of > maxage. > What if we receive a maxaged lsa and the current copy in the database > maxages at exactly > the same time. > According to section 13.1 these two lsas will be considered identical > (assuming sequence number etc. is the same). > However, what could be the possible disadvantage of > treating the received maxage lsa as the more current one, replacing the > database copy with this lsa and flooding it out to our neighbors. Hello Gargi, In either case, the LSA is purged from the OSPF routing domain. Hence, I don't see any disadvantage to considering the two MAXAGE'ed LSA instances identical. Thanks, Acee > > Thanks in advance, > Gargi > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Fri Jan 17 03:54:08 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15853 for ; Fri, 17 Jan 2003 03:54:07 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00897902@cherry.ease.lsoft.com>; Fri, 17 Jan 2003 3:57:28 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 609896 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 17 Jan 2003 03:57:28 -0500 Received: from 203.199.83.248 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 17 Jan 2003 03:47:27 -0500 Received: (qmail 25090 invoked by uid 510); 17 Jan 2003 08:45:55 -0000 Received: from unknown (203.197.138.201) by rediffmail.com via HTTP; 17 jan 2003 08:45:55 -0000 MIME-Version: 1.0 Content-type: text/plain; format=flowed Content-Disposition: inline Message-ID: <20030117084555.25089.qmail@webmail36.rediffmail.com> Date: Fri, 17 Jan 2003 08:45:55 -0000 Reply-To: Mailing List Sender: Mailing List From: arunsy Subject: Re: Determining which LSA is newer To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Gargi, If the received LSA has MAX Age, it signifies that the LSA in the Database has to be flushed. The Router which had originated the LSA previously floods the same LSA with MAX Age if the LSA is timedout due to Normal LSA Aging or Premature Aging. So LSA received with MAX Age should be the recent LSA. With Regards, ARun Y. On Thu, 16 Jan 2003 Banerjee, Gargi wrote : >Hi, >I had a question regarding section 13.1 (Determining which lsa is >newer) in >rfc 2328. >Bullet 3 in the above section says : > >Else, if only one of the instances has its LS age field set >to MaxAge, the instance of age MaxAge is considered to be >more recent. > >I was wondering why we are specific about exactly one of the lsas >being of >maxage. >What if we receive a maxaged lsa and the current copy in the >database >maxages at exactly >the same time. >According to section 13.1 these two lsas will be considered >identical >(assuming sequence number etc. is the same). >However, what could be the possible disadvantage of >treating the received maxage lsa as the more current one, >replacing the >database copy with this lsa and flooding it out to our >neighbors. > >Thanks in advance, >Gargi From owner-ospf@DISCUSS.MICROSOFT.COM Mon Jan 20 11:01:02 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22565 for ; Mon, 20 Jan 2003 11:01:00 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.0089DA81@cherry.ease.lsoft.com>; Mon, 20 Jan 2003 11:04:20 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 617788 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 20 Jan 2003 11:04:20 -0500 Received: from 171.71.163.11 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 20 Jan 2003 11:04:20 -0500 Received: from cisco.com (megha.cisco.com [192.122.173.140]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h0KG4IFp021891 for ; Mon, 20 Jan 2003 08:04:18 -0800 (PST) Received: from ROJOSEW2K ([10.77.139.156]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with SMTP id VAA13657; Mon, 20 Jan 2003 21:33:16 +0530 (IST) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: <04dd01c2c09d$9597b0a0$9c8b4d0a@apac.cisco.com> Date: Mon, 20 Jan 2003 21:30:51 +0530 Reply-To: Mailing List Sender: Mailing List From: Roy Jose Subject: OSPF MIB support for multiple OSPF processes Comments: cc: akr@cisco.com, vswarup@cisco.com To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi, Rfc1850 doesn't talk about what to be done regarding the retrieval(GET) of MIB values when multiple OSPF processes exist on a router. Out first impression is to return details about all the processes. The problem is while selecting values for MIB objects like ospfRouterId,ospfAreaBdrRtrStatus, ospfASBdrRtrStatus etc. They may differ in separate processes. The Qn is, can we really support multiple processes with rfc1850? Thanks, Roy From owner-ospf@DISCUSS.MICROSOFT.COM Mon Jan 20 13:13:43 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26140 for ; Mon, 20 Jan 2003 13:13:42 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.0089DF3A@cherry.ease.lsoft.com>; Mon, 20 Jan 2003 13:17:03 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 618415 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 20 Jan 2003 13:17:03 -0500 Received: from 62.241.160.73 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 20 Jan 2003 13:17:03 -0500 Received: from tom3 (usermh27.uk.uudial.com [62.188.122.112]) by colossus.systems.pipex.net (Postfix) with SMTP id 80C9A160002E5 for ; Mon, 20 Jan 2003 18:17:01 +0000 (GMT) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Message-ID: <001801c2c0af$f1b55d80$0301a8c0@tom3> Date: Mon, 20 Jan 2003 18:15:38 -0000 Reply-To: Mailing List Sender: Mailing List From: Tom Petch Subject: Re: OSPF MIB support for multiple OSPF processes To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Yes. In SNMPv1, this can be done by having multiple 'agents' identified by different community names or different IP addresses, each accessing a distinct incarnation of MIB II and its subordinate branches. In SNMPv3, there is a more sophisticated mechanism of contexts which formalises the techniques given above. I do not think you should ever return more than one instance of a given object in GET or GETNEXT. Tom Petch nwnetworks@dial.pipex.com -----Original Message----- From: Roy Jose To: OSPF@DISCUSS.MICROSOFT.COM Date: 20 January 2003 16:04 Subject: OSPF MIB support for multiple OSPF processes >Hi, > >Rfc1850 doesn't talk about what to be done regarding the retrieval(GET) of >MIB values when multiple OSPF processes exist on a router. Out first >impression is to return details about all the processes. The problem is >while selecting values for MIB objects like >ospfRouterId,ospfAreaBdrRtrStatus, ospfASBdrRtrStatus etc. They may differ >in separate processes. The Qn is, can we really support multiple processes >with rfc1850? > >Thanks, >Roy From owner-ospf@DISCUSS.MICROSOFT.COM Tue Jan 21 04:41:43 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24506 for ; Tue, 21 Jan 2003 04:41:42 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.008A026A@cherry.ease.lsoft.com>; Tue, 21 Jan 2003 4:45:05 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 620680 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 21 Jan 2003 04:45:05 -0500 Received: from 171.70.157.152 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 21 Jan 2003 04:45:05 -0500 Received: from cisco.com (megha.cisco.com [192.122.173.140]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id h0L9j1uV001898 for ; Tue, 21 Jan 2003 01:45:01 -0800 (PST) Received: from ROJOSEW2K ([10.77.139.156]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with SMTP id PAA04864 for ; Tue, 21 Jan 2003 15:14:01 +0530 (IST) References: <001801c2c0af$f1b55d80$0301a8c0@tom3> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: <071501c2c131$c4d86730$9c8b4d0a@apac.cisco.com> Date: Tue, 21 Jan 2003 15:15:01 +0530 Reply-To: Mailing List Sender: Mailing List From: Roy Jose Subject: Re: OSPF MIB support for multiple OSPF processes To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi Tom, Thanks. > Yes. > In SNMPv1, this can be done by having multiple 'agents' identified by > different community names or different IP addresses, each accessing a > distinct incarnation of MIB II and its subordinate branches. Say OSPF process 2 is mapped to a MIB view V1. How does the NMS know the details it collects through SNMP GET/GETNEXT are meant for process 2? I doubt if this MIB view concept is based on MIB object id's, meaning we may not be able to have separate MIB views for each OSPF processes since we can't map them to any object id's. Thanks, Roy > In SNMPv3, there is a more sophisticated mechanism of contexts which > formalises the techniques given above. > I do not think you should ever return more than one instance of a > given object in GET or GETNEXT. > > Tom Petch > nwnetworks@dial.pipex.com > > -----Original Message----- > From: Roy Jose > To: OSPF@DISCUSS.MICROSOFT.COM > Date: 20 January 2003 16:04 > Subject: OSPF MIB support for multiple OSPF processes > > > >Hi, > > > >Rfc1850 doesn't talk about what to be done regarding the > retrieval(GET) of > >MIB values when multiple OSPF processes exist on a router. Out first > >impression is to return details about all the processes. The problem > is > >while selecting values for MIB objects like > >ospfRouterId,ospfAreaBdrRtrStatus, ospfASBdrRtrStatus etc. They may > differ > >in separate processes. The Qn is, can we really support multiple > processes > >with rfc1850? > > > >Thanks, > >Roy > From owner-ospf@DISCUSS.MICROSOFT.COM Tue Jan 21 07:51:50 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27407 for ; Tue, 21 Jan 2003 07:51:49 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.008A02F4@cherry.ease.lsoft.com>; Tue, 21 Jan 2003 7:55:13 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 621207 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 21 Jan 2003 07:55:13 -0500 Received: from 202.54.64.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 21 Jan 2003 07:55:12 -0500 Received: by GANESH with Internet Mail Service (5.5.2653.19) id ; Tue, 21 Jan 2003 18:26:23 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <55E277B99171E041ABF5F4B1C6DDCA06011FC94D@haritha.hclt.com> Date: Tue, 21 Jan 2003 18:27:29 +0530 Reply-To: Mailing List Sender: Mailing List From: "Jeyanath Minto J - CTD, Chennai." Subject: one more OSPF MIB Question To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list hi, In common practice Loopback interfaces are Advertise to all areas. But in rfc1850, ospfHostAreaID is not a Index of ospfHostEntry. My Question is, dont we add the area Id also as index of the host table? The Index must be {ospfHostIpAddress, ospfHostTOS, ospfHostAreaID }. am i right ? or is anyother solution exist ? Cheers Minto -----Original Message----- From: Roy Jose [mailto:rojose@CISCO.COM] Sent: Monday, January 20, 2003 9:31 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: OSPF MIB support for multiple OSPF processes Hi, Rfc1850 doesn't talk about what to be done regarding the retrieval(GET) of MIB values when multiple OSPF processes exist on a router. Out first impression is to return details about all the processes. The problem is while selecting values for MIB objects like ospfRouterId,ospfAreaBdrRtrStatus, ospfASBdrRtrStatus etc. They may differ in separate processes. The Qn is, can we really support multiple processes with rfc1850? Thanks, Roy From owner-ospf@DISCUSS.MICROSOFT.COM Tue Jan 21 09:03:23 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00578 for ; Tue, 21 Jan 2003 09:03:22 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.008A04F2@cherry.ease.lsoft.com>; Tue, 21 Jan 2003 9:06:41 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 621341 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 21 Jan 2003 09:06:42 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 21 Jan 2003 09:06:41 -0500 Received: from redback.com (login001.redback.com [155.53.12.18]) by prattle.redback.com (Postfix) with ESMTP id EE3012E6282 for ; Tue, 21 Jan 2003 06:06:39 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <55E277B99171E041ABF5F4B1C6DDCA06011FC94D@haritha.hclt.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E2D541F.3040602@redback.com> Date: Tue, 21 Jan 2003 09:07:27 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: one more OSPF MIB Question To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Jeyanath Minto J - CTD, Chennai. wrote: > hi, > In common practice Loopback interfaces are Advertise to all areas. This isn't part of the OSPF standard. In fact, it has been my experience that some implementations will occillate between areas when the same stub network is advertised in multiple areas. > But in rfc1850, ospfHostAreaID is not a Index of ospfHostEntry. > My Question is, dont we add the area Id also as index of the host > table? > The Index must be {ospfHostIpAddress, ospfHostTOS, ospfHostAreaID }. > am i right ? or is anyother solution exist ? > > Cheers > Minto > > > > -----Original Message----- > From: Roy Jose [mailto:rojose@CISCO.COM] > Sent: Monday, January 20, 2003 9:31 PM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: OSPF MIB support for multiple OSPF processes > > > Hi, > > Rfc1850 doesn't talk about what to be done regarding the retrieval(GET) of > MIB values when multiple OSPF processes exist on a router. Out first > impression is to return details about all the processes. The problem is > while selecting values for MIB objects like > ospfRouterId,ospfAreaBdrRtrStatus, ospfASBdrRtrStatus etc. They may differ > in separate processes. The Qn is, can we really support multiple processes > with rfc1850? > > Thanks, > Roy > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Tue Jan 21 09:56:46 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01626 for ; Tue, 21 Jan 2003 09:56:46 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.008A05B7@cherry.ease.lsoft.com>; Tue, 21 Jan 2003 10:00:10 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 621648 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 21 Jan 2003 10:00:10 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 21 Jan 2003 10:00:09 -0500 Received: from redback.com (login001.redback.com [155.53.12.18]) by prattle.redback.com (Postfix) with ESMTP id A4FD22E6294 for ; Tue, 21 Jan 2003 07:00:08 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <001801c2c0af$f1b55d80$0301a8c0@tom3> <071501c2c131$c4d86730$9c8b4d0a@apac.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E2D60A7.7010309@redback.com> Date: Tue, 21 Jan 2003 10:00:55 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: OSPF MIB support for multiple OSPF processes To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Roy, Tom, Using a separate community per instance works quite naturally if you have a virtual router model where each virtual router has its own SNMP configuration, RIB, and routing protocol instances. Our product uses this technique. However, within a virtual router (we call them contexts) one still has the problem when multiple routing protocol instances and RIBs are supported. The problem isn't unique to OSPF so I don't think an OSPFv2 specific solution is appropriate. I don't think making everything a table and adding instance ID as a table index is desirable. Roy Jose wrote: > Hi Tom, > > Thanks. > > >>Yes. >>In SNMPv1, this can be done by having multiple 'agents' identified by >>different community names or different IP addresses, each accessing a >>distinct incarnation of MIB II and its subordinate branches. > > > Say OSPF process 2 is mapped to a MIB view V1. How does the NMS know the > details it collects through SNMP GET/GETNEXT are meant for process 2? > > I doubt if this MIB view concept is based on MIB object id's, meaning we may > not be able to have separate MIB views for each OSPF processes since we > can't map them to any object id's. > > Thanks, > Roy > > >>In SNMPv3, there is a more sophisticated mechanism of contexts which >>formalises the techniques given above. >>I do not think you should ever return more than one instance of a >>given object in GET or GETNEXT. >> >>Tom Petch >>nwnetworks@dial.pipex.com >> >>-----Original Message----- >>From: Roy Jose >>To: OSPF@DISCUSS.MICROSOFT.COM >>Date: 20 January 2003 16:04 >>Subject: OSPF MIB support for multiple OSPF processes >> >> >> >>>Hi, >>> >>>Rfc1850 doesn't talk about what to be done regarding the >> >>retrieval(GET) of >> >>>MIB values when multiple OSPF processes exist on a router. Out first >>>impression is to return details about all the processes. The problem >> >>is >> >>>while selecting values for MIB objects like >>>ospfRouterId,ospfAreaBdrRtrStatus, ospfASBdrRtrStatus etc. They may >> >>differ >> >>>in separate processes. The Qn is, can we really support multiple >> >>processes >> >>>with rfc1850? >>> >>>Thanks, >>>Roy >> > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Tue Jan 21 12:04:45 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05298 for ; Tue, 21 Jan 2003 12:04:44 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.008A08C5@cherry.ease.lsoft.com>; Tue, 21 Jan 2003 12:08:08 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 622092 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 21 Jan 2003 12:08:08 -0500 Received: from 171.70.157.152 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 21 Jan 2003 12:08:08 -0500 Received: from cisco.com (megha.cisco.com [192.122.173.140]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id h0LH83uV025418 for ; Tue, 21 Jan 2003 09:08:04 -0800 (PST) Received: from ROJOSEW2K ([10.77.139.156]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with SMTP id WAA25685; Tue, 21 Jan 2003 22:37:04 +0530 (IST) References: <001801c2c0af$f1b55d80$0301a8c0@tom3> <071501c2c131$c4d86730$9c8b4d0a@apac.cisco.com> <3E2D60A7.7010309@redback.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: <09c701c2c16f$a97a9970$9c8b4d0a@apac.cisco.com> Date: Tue, 21 Jan 2003 22:38:04 +0530 Reply-To: Mailing List Sender: Mailing List From: Roy Jose Subject: Re: OSPF MIB support for multiple OSPF processes To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi Acee, > Roy, Tom, > > Using a separate community per instance works quite naturally if > you have a virtual router model where each virtual router has > its own SNMP configuration, RIB, and routing protocol instances. Our > product uses this technique. However, within a virtual router (we call > them contexts) one still has the problem when multiple routing protocol > instances and RIBs are supported. The problem isn't unique to OSPF so > I don't think an OSPFv2 specific solution is appropriate. I don't think > making everything a table and adding instance ID as a table index is > desirable. I am not able to think any other solution than going for this table option. I think adding an extra index to an existing table won't be a big issue. Only major change I can fprsee is the conversion of ospfGeneralGroup to a table. Thanks, Roy > > Roy Jose wrote: > > Hi Tom, > > > > Thanks. > > > > > >>Yes. > >>In SNMPv1, this can be done by having multiple 'agents' identified by > >>different community names or different IP addresses, each accessing a > >>distinct incarnation of MIB II and its subordinate branches. > > > > > > Say OSPF process 2 is mapped to a MIB view V1. How does the NMS know the > > details it collects through SNMP GET/GETNEXT are meant for process 2? > > > > I doubt if this MIB view concept is based on MIB object id's, meaning we may > > not be able to have separate MIB views for each OSPF processes since we > > can't map them to any object id's. > > > > Thanks, > > Roy > > > > > >>In SNMPv3, there is a more sophisticated mechanism of contexts which > >>formalises the techniques given above. > >>I do not think you should ever return more than one instance of a > >>given object in GET or GETNEXT. > >> > >>Tom Petch > >>nwnetworks@dial.pipex.com > >> > >>-----Original Message----- > >>From: Roy Jose > >>To: OSPF@DISCUSS.MICROSOFT.COM > >>Date: 20 January 2003 16:04 > >>Subject: OSPF MIB support for multiple OSPF processes > >> > >> > >> > >>>Hi, > >>> > >>>Rfc1850 doesn't talk about what to be done regarding the > >> > >>retrieval(GET) of > >> > >>>MIB values when multiple OSPF processes exist on a router. Out first > >>>impression is to return details about all the processes. The problem > >> > >>is > >> > >>>while selecting values for MIB objects like > >>>ospfRouterId,ospfAreaBdrRtrStatus, ospfASBdrRtrStatus etc. They may > >> > >>differ > >> > >>>in separate processes. The Qn is, can we really support multiple > >> > >>processes > >> > >>>with rfc1850? > >>> > >>>Thanks, > >>>Roy > >> > > > > > -- > Acee > From owner-ospf@DISCUSS.MICROSOFT.COM Thu Jan 23 13:53:08 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16488 for ; Thu, 23 Jan 2003 13:53:08 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.008A6876@cherry.ease.lsoft.com>; Thu, 23 Jan 2003 13:56:33 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 561128 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 23 Jan 2003 13:56:33 -0500 Received: from 62.241.160.73 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 23 Jan 2003 13:56:33 -0500 Received: from tom3 (userav32.uk.uudial.com [62.188.138.79]) by colossus.systems.pipex.net (Postfix) with SMTP id 0AD531600034E for ; Thu, 23 Jan 2003 18:56:31 +0000 (GMT) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Message-ID: <002d01c2c310$f31492a0$0301a8c0@tom3> Date: Thu, 23 Jan 2003 18:39:09 -0000 Reply-To: Mailing List Sender: Mailing List From: Tom Petch Subject: Re: OSPF MIB support for multiple OSPF processes To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Roy While I defer to Acee's expertise in OSPF, I may not necessarily do so with SNMP; I think that the SNMPv3 idea of context was created for just the situation you describe. A context, as discussed in RFC 3411 with its place in the PDU defined in RFC 3412, is an integral part of an SNMPv3 PDU. A simple 'agent' will just have the one, more sophisticated ones can have as many as they like, each identified by a name, so if you have multiple processes or objects of any kind where the MIB branch only allows one instance, then contexts is the technology that supports this. And there is no need to replicate any more of the MIB and associated structures than you need to, no need to have complete, multiple virtual routers. Also in SNMP, once a name has been registered, it cannot be substantially changed so if you want a table to replace a scalar, then you must create new names, new objects, for everything in the table; the old names may continue to be used for the existing scalar objects or may be deprecated but they cannot change meaning. Views, which you mention, are also a defined concept of SNMPv3 associated with access control, who can see which subset of the available objects; I do not see that as being appopriate here. I f you want an opinion on SNMP issues from a greater level of expertise, then there is a mailing list for just this purpose, namely mibs@ops.ietf.org Tom Petch nwnetworks@dial.pipex.com -----Original Message----- From: Roy Jose To: OSPF@DISCUSS.MICROSOFT.COM Date: 21 January 2003 17:08 Subject: Re: OSPF MIB support for multiple OSPF processes >Hi Acee, > >> Roy, Tom, >> >> Using a separate community per instance works quite naturally if >> you have a virtual router model where each virtual router has >> its own SNMP configuration, RIB, and routing protocol instances. Our >> product uses this technique. However, within a virtual router (we call >> them contexts) one still has the problem when multiple routing protocol >> instances and RIBs are supported. The problem isn't unique to OSPF so >> I don't think an OSPFv2 specific solution is appropriate. I don't think >> making everything a table and adding instance ID as a table index is >> desirable. > >I am not able to think any other solution than going for this table option. >I think adding an extra index to an existing table won't be a big issue. >Only major change I can fprsee is the conversion of ospfGeneralGroup to a >table. > >Thanks, >Roy > >> >> Roy Jose wrote: >> > Hi Tom, >> > >> > Thanks. >> > >> > >> >>Yes. >> >>In SNMPv1, this can be done by having multiple 'agents' identified by >> >>different community names or different IP addresses, each accessing a >> >>distinct incarnation of MIB II and its subordinate branches. >> > >> > >> > Say OSPF process 2 is mapped to a MIB view V1. How does the NMS know the >> > details it collects through SNMP GET/GETNEXT are meant for process 2? >> > >> > I doubt if this MIB view concept is based on MIB object id's, meaning we >may >> > not be able to have separate MIB views for each OSPF processes since we >> > can't map them to any object id's. >> > >> > Thanks, >> > Roy >> > >> > >> >>In SNMPv3, there is a more sophisticated mechanism of contexts which >> >>formalises the techniques given above. >> >>I do not think you should ever return more than one instance of a >> >>given object in GET or GETNEXT. >> >> >> >>Tom Petch >> >>nwnetworks@dial.pipex.com >> >> >> >>-----Original Message----- >> >>From: Roy Jose >> >>To: OSPF@DISCUSS.MICROSOFT.COM >> >>Date: 20 January 2003 16:04 >> >>Subject: OSPF MIB support for multiple OSPF processes >> >> >> >> >> >> >> >>>Hi, >> >>> >> >>>Rfc1850 doesn't talk about what to be done regarding the >> >> >> >>retrieval(GET) of >> >> >> >>>MIB values when multiple OSPF processes exist on a router. Out first >> >>>impression is to return details about all the processes. The problem >> >> >> >>is >> >> >> >>>while selecting values for MIB objects like >> >>>ospfRouterId,ospfAreaBdrRtrStatus, ospfASBdrRtrStatus etc. They may >> >> >> >>differ >> >> >> >>>in separate processes. The Qn is, can we really support multiple >> >> >> >>processes >> >> >> >>>with rfc1850? >> >>> >> >>>Thanks, >> >>>Roy >> >> >> > >> >> >> -- >> Acee >> From owner-ospf@DISCUSS.MICROSOFT.COM Sat Jan 25 13:46:20 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26912 for ; Sat, 25 Jan 2003 13:46:20 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.008B09C8@cherry.ease.lsoft.com>; Sat, 25 Jan 2003 13:49:46 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 566087 for OSPF@DISCUSS.MICROSOFT.COM; Sat, 25 Jan 2003 13:49:46 -0500 Received: from 206.46.170.142 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sat, 25 Jan 2003 13:39:46 -0500 Received: from micros ([4.46.41.210]) by out004.verizon.net (InterMail vM.5.01.05.20 201-253-122-126-120-20021101) with ESMTP id <20030125183944.JQNC2505.out004.verizon.net@micros>; Sat, 25 Jan 2003 12:39:44 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C2C45E.89F722C0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Authentication-Info: Submitted using SMTP AUTH at out004.verizon.net from [4.46.41.210] at Sat, 25 Jan 2003 12:39:38 -0600 Message-ID: <000001c2c4a1$981a62c0$6419028b@kpxsys.com> Date: Sat, 25 Jan 2003 10:42:57 -0800 Reply-To: Mailing List Sender: Mailing List From: Kip Palmer Subject: Kip Palmer/ New contact info Comments: To: admin@imrmls.com, "Alaric Dimanalaric423@yahoo. com" , amir@superlative.com, "Amznggr8ce@Aol. Com" , "Angel (Angel)" , anthony@imrmls.com, "Arian Hayes (Arian Hayes)" , "Arnold Recendez (Arnold Recendez)" , "Arnoldw (Arnoldw)" , Bernard Omrani , Brian Chen , Butch@streamlinecomputers.com, Ccie Study , "Ccielab@Groupstudy. Com" , ccielab@groupstudy.com, "Chuck@MLSphotos. com" , DAD , Dad , "Dale A. Bork" , Dave , "Dave Saller (Dave Saller)" , "Dave@Imrmls. Com" , dave@imrmls.com, Dean Rosile , "DENEENw (DENEENw)" , "DERRICK (DERRICK)" , "DOMINICw (DOMINICw)" , "DONNAw (DONNAw)" , Editor@j4femail.com, ejsharp@pacbell.com, "Erica Von Michaelis (erica von michaelis)" , "Forrest Pascal (Forrest Pascal)" , "GREG (GREG)" , Greg Larson , gwen@imrmls.com, Ian Hodge , jason.barbata@jetdelivery.com, Jason Barbee , JBarbee , "John (John)" , John Mistichelli , Johnathan Cohen , "JOHNNYh (JOHNNYh)" , "JOHNNYw (JOHNNYw)" , "Jose Vidauri-IMRMLS (Jose Vidauri-IMRMLS)" , kathy@imrmls.com, "Kip Palmer (Kip Palmer)" , "Kip_work (Kip_work)" , kpsalami@aol.com, "Les_English (les_english)" , "Main Identity (Main Identity)" , Mardi Wood , "Martha Ferrer (Martha Ferrer)" , "Michellew (Michellew)" , "Mike Kelly (Mike Kelly)" , "Mikelong (Mikelong)" , "Minesh_Hm (Minesh_Hm)" , "Minesh_work (Minesh_work)" , "MOM (MOM)" , mrussell@ccbootcamp.com, nshah@connect.com.au, "NITIN (NITIN)" , "Nobody@Groupstudy. Com" , nobody@groupstudy.com, "Otto (Otto)" , "Parci (Parci)" , "Patric Murphy (Patric Murphy)" , "PATw (PATw)" , "PMMurphy (PMMurphy)" , "PMurphy (PMurphy)" , raj@iparikh.com, "RAJgomail (RAJgomail)" , "RAJyahoo (RAJyahoo)" , "Robby (Robby)" , "Robert J. DeVassie (Robert J. DeVassie)" , "Rod (Rod)" , "Rodnw (Rodnw)" , ronna@coastesa.com, RonCPalmer , Sally Liu , scott@swedausa.com, Sean O'Shea , "SHELLY (SHELLY)" , steven@imrmls.com, stewart@imrmls.com, stewart@imrmls.com, support@realrouterlabs.com, Sysadmin , Sysadmin , "Thomas Tyler (Thomas Tyler)" , "Tina Dubreuil (Tina Dubreuil)" , "UncleRob (UncleRob)" , admin@vconsole.net, vicky@imrmls.com, "VINNY (VINNY)" , walter@imrmls.com, "Xyriz Pasco (Xyriz Pasco)" To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C2C45E.89F722C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit ---------------------------- 8am - 6pm Monday thru Friday Kip Palmer Network Engineer kpalmer@fnis.com 949.797.8465 Ext. 8465 Office 909.374.6865 Cell 949.221.2435 FAX Fidelity National Information Solutions 2510 N. Red Hill, Santa Ana, CA 92705 --------------------------- Kip Palmer kip.palmer@verizon.net 909.374.6865 cell 909.596.2612 fax 909.596.6403 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Privacy Notice: This message is intended only for the use of the individual or entity to whom it is addressed and may contain information that is privileged, confidential, or exempt from disclosure under applicable federal or state law. If the reader of this message is not the intended recipient or the employee or agents responsible for delivering the message to the intended recipient you are hereby notified that any dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please return to:kip.palmer@verizon.net, THANK YOU! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ------=_NextPart_000_0001_01C2C45E.89F722C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message

----------------------------

8am - 6pm Monday thru = Friday

Kip Palmer
Network Engineer

kpalmer@fnis.com =
949.797.8465  Ext. 8465 Office
909.374.6865=20 Cell
949.221.2435 FAX
  =
Fidelity National Information Solutions =
2510 N. Red Hill, Santa Ana, CA  = 92705=20

---------------------------
 
 
Kip Palmer
kip.palmer@verizon.net
909.374.6865 = cell
909.596.2612 = fax
909.596.6403
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Privacy = Notice:
 
This = message is intended=20 only for the use of the individual or entity to whom it is addressed and = may=20 contain information that is privileged, confidential, or exempt from = disclosure=20 under applicable federal or state law. If the reader of this message is = not the=20 intended recipient or the employee or agents responsible for delivering = the=20 message to the intended recipient you are hereby notified that any=20 dissemination, distribution, or copying of this message is strictly = prohibited.=20 If you have received this communication in error, please return to:kip.palmer@verizon.net, <= /FONT>
THANK = YOU!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
------=_NextPart_000_0001_01C2C45E.89F722C0-- From owner-ospf@DISCUSS.MICROSOFT.COM Mon Jan 27 18:09:02 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00325 for ; Mon, 27 Jan 2003 18:09:02 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.008B8B3A@cherry.ease.lsoft.com>; Mon, 27 Jan 2003 18:12:31 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 574055 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 27 Jan 2003 18:12:31 -0500 Received: from 171.70.145.30 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 27 Jan 2003 18:12:31 -0500 Received: from cisco.com (megha.cisco.com [192.122.173.140]) by sj-msg-core-2.cisco.com (8.12.2/8.12.6) with ESMTP id h0RNCNsv017715 for ; Mon, 27 Jan 2003 15:12:24 -0800 (PST) Received: from ROJOSEW2K ([10.77.139.156]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with SMTP id EAA25059 for ; Tue, 28 Jan 2003 04:41:24 +0530 (IST) References: <002d01c2c310$f31492a0$0301a8c0@tom3> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: <07a201c2c659$8f42e4b0$9c8b4d0a@apac.cisco.com> Date: Tue, 28 Jan 2003 04:42:27 +0530 Reply-To: Mailing List Sender: Mailing List From: Roy Jose Subject: Re: OSPF MIB support for multiple OSPF processes To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi Tom, Thanks very much for your suggestion. Let me do more investigations on this and get back to you. Roy > Roy > > While I defer to Acee's expertise in OSPF, I may not necessarily do so > with SNMP; I think that the SNMPv3 idea of context was created for > just > the situation you describe. A context, as discussed in RFC 3411 with > its place in the PDU defined in RFC 3412, is an integral > part of an SNMPv3 PDU. A simple 'agent' will just have the one, > more sophisticated ones can have as many as they like, each > identified by a name, so if you have multiple processes or objects of > any kind where the MIB branch only allows one instance, then contexts > is the technology that supports this. And there is no need to > replicate any more of the MIB and associated structures than you need > to, no need to have complete, multiple virtual routers. > > Also in SNMP, once a name has been registered, it cannot be > substantially > changed so if you want a table to replace a scalar, then you must > create new names, new objects, for everything in the table; the old > names may continue to be used for the existing scalar objects or > may be deprecated but they cannot change meaning. > > Views, which you mention, are also a defined concept of SNMPv3 > associated with access control, who can see which subset of the > available objects; I do not see that as being appopriate here. > > I f you want an opinion on SNMP issues from a greater level of > expertise, then there > is a mailing list for just this purpose, namely > mibs@ops.ietf.org > > Tom Petch > nwnetworks@dial.pipex.com > > -----Original Message----- > From: Roy Jose > To: OSPF@DISCUSS.MICROSOFT.COM > Date: 21 January 2003 17:08 > Subject: Re: OSPF MIB support for multiple OSPF processes > > > >Hi Acee, > > > >> Roy, Tom, > >> > >> Using a separate community per instance works quite naturally if > >> you have a virtual router model where each virtual router has > >> its own SNMP configuration, RIB, and routing protocol instances. > Our > >> product uses this technique. However, within a virtual router (we > call > >> them contexts) one still has the problem when multiple routing > protocol > >> instances and RIBs are supported. The problem isn't unique to OSPF > so > >> I don't think an OSPFv2 specific solution is appropriate. I don't > think > >> making everything a table and adding instance ID as a table index > is > >> desirable. > > > >I am not able to think any other solution than going for this table > option. > >I think adding an extra index to an existing table won't be a big > issue. > >Only major change I can fprsee is the conversion of ospfGeneralGroup > to a > >table. > > > >Thanks, > >Roy > > > >> > >> Roy Jose wrote: > >> > Hi Tom, > >> > > >> > Thanks. > >> > > >> > > >> >>Yes. > >> >>In SNMPv1, this can be done by having multiple 'agents' > identified by > >> >>different community names or different IP addresses, each > accessing a > >> >>distinct incarnation of MIB II and its subordinate branches. > >> > > >> > > >> > Say OSPF process 2 is mapped to a MIB view V1. How does the NMS > know the > >> > details it collects through SNMP GET/GETNEXT are meant for > process 2? > >> > > >> > I doubt if this MIB view concept is based on MIB object id's, > meaning we > >may > >> > not be able to have separate MIB views for each OSPF processes > since we > >> > can't map them to any object id's. > >> > > >> > Thanks, > >> > Roy > >> > > >> > > >> >>In SNMPv3, there is a more sophisticated mechanism of contexts > which > >> >>formalises the techniques given above. > >> >>I do not think you should ever return more than one instance of a > >> >>given object in GET or GETNEXT. > >> >> > >> >>Tom Petch > >> >>nwnetworks@dial.pipex.com > >> >> > >> >>-----Original Message----- > >> >>From: Roy Jose > >> >>To: OSPF@DISCUSS.MICROSOFT.COM > >> >>Date: 20 January 2003 16:04 > >> >>Subject: OSPF MIB support for multiple OSPF processes > >> >> > >> >> > >> >> > >> >>>Hi, > >> >>> > >> >>>Rfc1850 doesn't talk about what to be done regarding the > >> >> > >> >>retrieval(GET) of > >> >> > >> >>>MIB values when multiple OSPF processes exist on a router. Out > first > >> >>>impression is to return details about all the processes. The > problem > >> >> > >> >>is > >> >> > >> >>>while selecting values for MIB objects like > >> >>>ospfRouterId,ospfAreaBdrRtrStatus, ospfASBdrRtrStatus etc. They > may > >> >> > >> >>differ > >> >> > >> >>>in separate processes. The Qn is, can we really support multiple > >> >> > >> >>processes > >> >> > >> >>>with rfc1850? > >> >>> > >> >>>Thanks, > >> >>>Roy > >> >> > >> > > >> > >> > >> -- > >> Acee > >> > From owner-ospf@DISCUSS.MICROSOFT.COM Wed Jan 29 08:45:00 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19146 for ; Wed, 29 Jan 2003 08:44:59 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.008BCDED@cherry.ease.lsoft.com>; Wed, 29 Jan 2003 8:48:29 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 581056 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 29 Jan 2003 08:48:29 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 29 Jan 2003 08:48:29 -0500 Received: from redback.com (login001.redback.com [155.53.12.18]) by prattle.redback.com (Postfix) with ESMTP id 4AEA81DBAD for ; Wed, 29 Jan 2003 05:48:28 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E37DB74.8000800@redback.com> Date: Wed, 29 Jan 2003 08:47:32 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: OSPF List Status To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit As of 9:00 AM EST on 1/29/02, the IETF OSPF list still appears to be down. This is a test posting. -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Wed Jan 29 08:56:51 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19510 for ; Wed, 29 Jan 2003 08:56:51 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.008BCE55@cherry.ease.lsoft.com>; Wed, 29 Jan 2003 9:00:22 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 581132 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 29 Jan 2003 09:00:22 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 29 Jan 2003 09:00:22 -0500 Received: from redback.com (login001.redback.com [155.53.12.18]) by prattle.redback.com (Postfix) with ESMTP id B18EC1DBAD for ; Wed, 29 Jan 2003 05:59:32 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E37DE0C.8090206@redback.com> Date: Wed, 29 Jan 2003 08:58:36 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Working Group Last Call for draft-ietf-ospf-hitless-restart-05.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit This is the start of a Working Group last call for draft-ietf-ospf-hitless-restart-05.txt, OSPF Hitless Restart. All comments must be sent to the OSPF list by Friday, February 8th, 2003. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-hitless-restart-05.txt My previous list posting on this WG last call was lost or filtering. My apologies if this is a duplicate. Thanks, Acee & Rohit -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Wed Jan 29 09:16:02 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20004 for ; Wed, 29 Jan 2003 09:16:02 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.008BCF9F@cherry.ease.lsoft.com>; Wed, 29 Jan 2003 9:19:33 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 581195 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 29 Jan 2003 09:19:33 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 29 Jan 2003 09:19:33 -0500 Received: from redback.com (login001.redback.com [155.53.12.18]) by prattle.redback.com (Postfix) with ESMTP id 869D321EFA1 for ; Wed, 29 Jan 2003 06:19:32 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <3E37DB74.8000800@redback.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E37E2BC.7020507@redback.com> Date: Wed, 29 Jan 2003 09:18:36 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: OSPF List Status To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Acee Lindem wrote: > As of 9:00 AM EST on 1/29/02, the IETF OSPF list still appears to > be down. This is a test posting. It appears that one of my list postings was filtered due to the fact that I forwarded the IETF announce E-mail along with the WG last call notification. I assume this is to prevent duplication of the IETF announcements. There wasn't a problem with the OSPF list. -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Wed Jan 29 15:53:39 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29654 for ; Wed, 29 Jan 2003 15:53:39 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.008BDE72@cherry.ease.lsoft.com>; Wed, 29 Jan 2003 15:57:08 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 583129 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 29 Jan 2003 15:57:09 -0500 Received: from 151.118.3.177 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 29 Jan 2003 15:47:09 -0500 Received: by nomad.tcb.net (Postfix, from userid 500) id 1FBBE55F62; Wed, 29 Jan 2003 13:47:07 -0700 (MST) Received: from nomad.tcb.net (localhost [127.0.0.1]) by nomad.tcb.net (Postfix) with ESMTP id E253F3E83 for ; Wed, 29 Jan 2003 13:47:07 -0700 (MST) Delivery-Date: Wed, 29 Jan 2003 13:45:15 -0700 Delivered-To: danny@localhost.tcb.net Received: from localhost (unknown [127.0.0.1]) by nomad.tcb.net (Postfix) with ESMTP id 2AEA455F62 for ; Wed, 29 Jan 2003 13:45:15 -0700 (MST) Delivered-To: danny@tcb.net Received: from dog.tcb.net [64.78.150.133] by localhost with IMAP (fetchmail-6.1.2) for danny@localhost (single-drop); Wed, 29 Jan 2003 13:45:15 -0700 (MST) Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by dog.tcb.net (Postfix) with ESMTP id 4A88C20298 for ; Wed, 29 Jan 2003 13:49:16 -0700 (MST) Received: by trapdoor.merit.edu (Postfix) id EC0A991378; Wed, 29 Jan 2003 15:40:42 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3482D9137A; Wed, 29 Jan 2003 15:40:39 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F361B91378 for ; Wed, 29 Jan 2003 15:40:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id D06D25DF0F; Wed, 29 Jan 2003 15:40:34 -0500 (EST) Delivered-To: idr@merit.edu Received: from nomad.tcb.net (vdsl-151-118-3-177.dnvr.uswest.net [151.118.3.177]) by segue.merit.edu (Postfix) with ESMTP id A1A865DE6B for ; Wed, 29 Jan 2003 15:40:34 -0500 (EST) Received: by nomad.tcb.net (Postfix, from userid 500) id 309D055F62; Wed, 29 Jan 2003 13:40:34 -0700 (MST) Received: from nomad.tcb.net (localhost [127.0.0.1]) by nomad.tcb.net (Postfix) with ESMTP id 2FFD33E83; Wed, 29 Jan 2003 13:40:34 -0700 (MST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Precedence: bulk Message-ID: <20030129204707.1FBBE55F62@nomad.tcb.net> Date: Wed, 29 Jan 2003 13:47:02 -0700 Reply-To: Mailing List Sender: Mailing List Comments: Resent-From: Danny McPherson Comments: Originally-From: Danny McPherson From: Danny McPherson Subject: GR/NSF Terminology To: OSPF@DISCUSS.MICROSOFT.COM [Folks, notice the cross-post... Perhaps routing-discussion@ietf.org should be the only one to receive replies, please try to respect this]. I think it'd be a good thing for all of the GR/NSF protocol extensions to employ a common set of terminology, instead of each using your own. I believe the OSPF *WG* document currently does the best job with defining terms, etc.., although I'm not sure it's sufficient or accommodates everything. I'd be willing to work on a "generic document" if need be, or would be happy if the current protocol-specific documents (i.e., BGP, IS-IS, OSPF, LDP, RSVP (dead?), VPN stuff, other?) would make some attempt to use the same terms. Any comments? -danny > This is the start of a Working Group last call for > draft-ietf-ospf-hitless-restart-05.txt, OSPF Hitless Restart. > All comments must be sent to the OSPF list by Friday, > February 8th, 2003. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ospf-hitless-restart-05.txt > > My previous list posting on this WG last call was lost or > filtering. My apologies if this is a duplicate. > > Thanks, > Acee & Rohit > -- > Acee From owner-ospf@DISCUSS.MICROSOFT.COM Thu Jan 30 14:17:26 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07759 for ; Thu, 30 Jan 2003 14:17:26 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.008C040F@cherry.ease.lsoft.com>; Thu, 30 Jan 2003 14:20:57 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 587167 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 30 Jan 2003 14:20:57 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 30 Jan 2003 14:20:56 -0500 Received: from redback.com (login003.redback.com [155.53.12.55]) by prattle.redback.com (Postfix) with ESMTP id 314EF2CD604; Thu, 30 Jan 2003 11:20:54 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E397ACD.3020704@redback.com> Date: Thu, 30 Jan 2003 14:19:41 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: [Fwd: Re: GR/NSF Terminology] Comments: To: Padma Pillay-Esnault To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit I support changing "hitless" to "graceful" in the OSPF draft to be consistent with the other protocol documents. I'll leave the file name the same for continuity but it will be "graceful restart" once it is published as an RFC. Any thoughts on this? This change would be based on a discussion on the main routing discussion list (see below). -------- Original Message -------- Subject: Re: GR/NSF Terminology Date: Thu, 30 Jan 2003 08:33:58 -0700 From: Danny McPherson Reply-To: danny@tcb.net To: routing-discussion@ietf.org > The OSPF document you cite defines various terms, but in an > OSPF-specific fashion. Furthermore, the definitions are not > collected anywhere in the document but are peppered throughout it... > which is fine in context but doesn't lend itself to generic use of > the terms. Agreed. > Seems like there are two things we could do: > > First, leave the documents as they are. This is my preferred > alternative. The docs are relatively well advanced in terms of > specification and even deployment, and doing what would be a > non-trivial update solely for the purpose of aligning terminology > strikes me a being work for work's sake. This is doubly true because > a major terminology change creates the risk of introducing subtle > errors to the spec if one isn't careful. Apart from aesthetics, what > need do you think is fulfilled by aligning the specs? > > Alternately, if we do want to go ahead and change the specs, then a > (generic) definitions document such as you have volunteered to write > seems a necessity. I'm not a fan of "framework" documents and I hope > we could keep the scope of the proposed definitions document focused. OK, so folks don't seem to be to keen on the idea at this point. Given that I'm not attached to the idea of more work "for the sake of work" then I'll drop it. I believe there is room for commonality but look where that's got me in PWE3 *8^/ > By the way, I think "graceful restart" has historic precedence over > "hitless restart" if you want to align terms :-). Agreed. -danny _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Thu Jan 30 14:21:57 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07923 for ; Thu, 30 Jan 2003 14:21:56 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.008C0528@cherry.ease.lsoft.com>; Thu, 30 Jan 2003 14:25:28 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 587216 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 30 Jan 2003 14:25:28 -0500 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 30 Jan 2003 14:25:28 -0500 Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h0UJPRS40744; Thu, 30 Jan 2003 11:25:27 -0800 (PST) (envelope-from padma@juniper.net) Received: (from padma@localhost) by garnet.juniper.net (8.11.5/8.11.3) id h0UJPRu50706; Thu, 30 Jan 2003 11:25:27 -0800 (PST) (envelope-from padma) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <200301301925.h0UJPRu50706@garnet.juniper.net> Date: Thu, 30 Jan 2003 11:25:27 -0800 Reply-To: Mailing List Sender: Mailing List From: Padma Pillay-Esnault Subject: Re: [Fwd: Re: GR/NSF Terminology] To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3E397ACD.3020704@redback.com> from "Acee Lindem" at Jan 30, 2003 02:19:41 PM Precedence: list Content-Transfer-Encoding: 7bit I fully support "graceful restart" Padma > > I support changing "hitless" to "graceful" in the > OSPF draft to be consistent with the other protocol documents. > I'll leave the file name the same for continuity but it will be > "graceful restart" once it is published as an RFC. Any thoughts on > this? This change would be based on a discussion on the main > routing discussion list (see below). > > > -------- Original Message -------- > Subject: Re: GR/NSF Terminology > Date: Thu, 30 Jan 2003 08:33:58 -0700 > From: Danny McPherson > Reply-To: danny@tcb.net > To: routing-discussion@ietf.org > > > > The OSPF document you cite defines various terms, but in an > > OSPF-specific fashion. Furthermore, the definitions are not > > collected anywhere in the document but are peppered throughout it... > > which is fine in context but doesn't lend itself to generic use of > > the terms. > > Agreed. > > > Seems like there are two things we could do: > > > > First, leave the documents as they are. This is my preferred > > alternative. The docs are relatively well advanced in terms of > > specification and even deployment, and doing what would be a > > non-trivial update solely for the purpose of aligning terminology > > strikes me a being work for work's sake. This is doubly true because > > a major terminology change creates the risk of introducing subtle > > errors to the spec if one isn't careful. Apart from aesthetics, what > > need do you think is fulfilled by aligning the specs? > > > > Alternately, if we do want to go ahead and change the specs, then a > > (generic) definitions document such as you have volunteered to write > > seems a necessity. I'm not a fan of "framework" documents and I hope > > we could keep the scope of the proposed definitions document focused. > > OK, so folks don't seem to be to keen on the idea at this point. > Given that I'm not attached to the idea of more work "for the > sake of work" then I'll drop it. I believe there is room for > commonality but look where that's got me in PWE3 *8^/ > > > > By the way, I think "graceful restart" has historic precedence over > > "hitless restart" if you want to align terms :-). > > Agreed. > > -danny > > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www1.ietf.org/mailman/listinfo/routing-discussion > > > -- > Acee > From owner-ospf@DISCUSS.MICROSOFT.COM Thu Jan 30 14:23:45 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07960 for ; Thu, 30 Jan 2003 14:23:45 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.008C0436@cherry.ease.lsoft.com>; Thu, 30 Jan 2003 14:27:17 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 587237 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 30 Jan 2003 14:27:17 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 30 Jan 2003 14:27:17 -0500 Received: from malt (malt.redback.com [155.53.12.41]) by prattle.redback.com (Postfix) with ESMTP id 5D2A72CD608 for ; Thu, 30 Jan 2003 11:27:13 -0800 (PST) X-Sender: rahul@malt MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Thu, 30 Jan 2003 11:27:13 -0800 Reply-To: Mailing List Sender: Mailing List From: Rahul Aggarwal Subject: Re: [Fwd: Re: GR/NSF Terminology] To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3E397ACD.3020704@redback.com> Precedence: list Hi Acee, On Thu, 30 Jan 2003, Acee Lindem wrote: > I support changing "hitless" to "graceful" in the > OSPF draft to be consistent with the other protocol documents. > I'll leave the file name the same for continuity but it will be > "graceful restart" once it is published as an RFC. Any thoughts on > this? This change would be based on a discussion on the main > routing discussion list (see below). I think that is a good idea. It will also help in making sure we don't have another terminology document being written :) thanks, rahul > > > -------- Original Message -------- > Subject: Re: GR/NSF Terminology > Date: Thu, 30 Jan 2003 08:33:58 -0700 > From: Danny McPherson > Reply-To: danny@tcb.net > To: routing-discussion@ietf.org > > > > The OSPF document you cite defines various terms, but in an > > OSPF-specific fashion. Furthermore, the definitions are not > > collected anywhere in the document but are peppered throughout it... > > which is fine in context but doesn't lend itself to generic use of > > the terms. > > Agreed. > > > Seems like there are two things we could do: > > > > First, leave the documents as they are. This is my preferred > > alternative. The docs are relatively well advanced in terms of > > specification and even deployment, and doing what would be a > > non-trivial update solely for the purpose of aligning terminology > > strikes me a being work for work's sake. This is doubly true because > > a major terminology change creates the risk of introducing subtle > > errors to the spec if one isn't careful. Apart from aesthetics, what > > need do you think is fulfilled by aligning the specs? > > > > Alternately, if we do want to go ahead and change the specs, then a > > (generic) definitions document such as you have volunteered to write > > seems a necessity. I'm not a fan of "framework" documents and I hope > > we could keep the scope of the proposed definitions document focused. > > OK, so folks don't seem to be to keen on the idea at this point. > Given that I'm not attached to the idea of more work "for the > sake of work" then I'll drop it. I believe there is room for > commonality but look where that's got me in PWE3 *8^/ > > > > By the way, I think "graceful restart" has historic precedence over > > "hitless restart" if you want to align terms :-). > > Agreed. > > -danny > > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www1.ietf.org/mailman/listinfo/routing-discussion > > > -- > Acee > From owner-ospf@DISCUSS.MICROSOFT.COM Thu Jan 30 21:26:01 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16477 for ; Thu, 30 Jan 2003 21:26:01 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.008C1246@cherry.ease.lsoft.com>; Thu, 30 Jan 2003 21:29:32 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 587958 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 30 Jan 2003 21:29:32 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 30 Jan 2003 21:29:32 -0500 Received: from redback.com (login003.redback.com [155.53.12.55]) by prattle.redback.com (Postfix) with ESMTP id 5B1233512EF for ; Thu, 30 Jan 2003 18:29:31 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E39DF3F.5080201@redback.com> Date: Thu, 30 Jan 2003 21:28:15 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: OSPF IGP Capabilities Draft To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit As many of you recall, we've discussed this draft at both the Yokohama and Atlanta OSPF WG meetings. I wasn't in Yokohama but apparently there were some present who voiced reservations with the draft. In Atlanta, there wasn't a lot of discussion (other than strong support from the authors ;^). We agreed to discuss this draft further on the OSPF list. Are there still people who have reservations with the draft? http://www.ietf.org/internet-drafts/draft-raggarwa-igp-cap-01.txt [Speaking as a WG member] I think the draft is a natural mechanism for advertising new OSPF capabilities now that the LSA option bits have been exhausted. We've already extended OSPF to support traffic engineering (TE) information and this mechanism is slated to be used for propagating an OSPF router's ability to act as an MPLS TE path computation server (PCS). Thanks, -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Fri Jan 31 05:13:06 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02753 for ; Fri, 31 Jan 2003 05:13:06 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.008C1E4A@cherry.ease.lsoft.com>; Fri, 31 Jan 2003 5:16:38 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 588594 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 31 Jan 2003 05:16:37 -0500 Received: from 64.106.140.220 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 31 Jan 2003 05:06:36 -0500 Received: from www.apara.com (localhost.localdomain [127.0.0.1]) by www.apara.com (8.11.6/8.11.6) with ESMTP id h0VAPvQ03916 for ; Fri, 31 Jan 2003 15:55:57 +0530 Received: from alok ([203.124.140.100]) (authenticated) by www.apara.com (8.11.6/8.11.6) with ESMTP id h0VAPst03909; Fri, 31 Jan 2003 15:55:54 +0530 References: <3E37DE0C.8090206@redback.com> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Message-ID: <067801c2c910$ba7fe9c0$81c802c0@alok> Date: Fri, 31 Jan 2003 15:38:21 +0530 Reply-To: Mailing List Sender: Mailing List From: alok Subject: Re: Working Group Last Call for draft-ietf-ospf-hitless-restart-05.txt Comments: cc: d.deepak@indiatimes.com To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi, there is something which I would appreciate if someone could clarify 1. what is "restarting" and what is "after restarting" state? essentially my concern being: page 2 (2) The restarting router runs its OSPF routing calculations, as specified in Section 16 of [1]. This is necessary to return any OSPF virtual links to operation. However, the restarting router does *not* install OSPF routes into the system's forwarding table(s), instead relying on the forwarding entries that it had installed prior to the restart. what does point 2 mean? again mentioned on 2.3 point 3, it says after it has "exited restart state" the routes will be put in the FT. what defines hitless restart time is the "grace period" which means "the router wont originate LSAs till LSRefreshtimer" : In order to avoid the restarting router's LSAs from aging out, the grace period should not exceed LSRefreshTime (1800 second) .....which anyways is the default operation if there is no topology change. (i hope I am right here) doing it this way implies that if there is a topology change elsewhere when the router is down, we would wait till the "old LSAs the router was orginating" become stale......to update the FT. so why "wait" for that time at all before updating the FT would making the simple test be "grace period is over as soon as OSPF reestablishes adjacencies and time passed since the begininning of restart is less than MinLSinterval"..hence start populating the FT with the new entries.... is my interpretation correct? -rgds Alok ----- Original Message ----- From: Acee Lindem To: Sent: Wednesday, January 29, 2003 7:28 PM Subject: Working Group Last Call for draft-ietf-ospf-hitless-restart-05.txt > This is the start of a Working Group last call for > draft-ietf-ospf-hitless-restart-05.txt, OSPF Hitless Restart. > All comments must be sent to the OSPF list by Friday, > February 8th, 2003. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ospf-hitless-restart-05.txt > > My previous list posting on this WG last call was lost or > filtering. My apologies if this is a duplicate. > > Thanks, > Acee & Rohit > -- > Acee > From owner-ospf@DISCUSS.MICROSOFT.COM Fri Jan 31 12:20:11 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12651 for ; Fri, 31 Jan 2003 12:20:11 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.008C2DE3@cherry.ease.lsoft.com>; Fri, 31 Jan 2003 12:23:44 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 590070 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 31 Jan 2003 12:23:44 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 31 Jan 2003 12:23:43 -0500 Received: from redback.com (login003.redback.com [155.53.12.55]) by prattle.redback.com (Postfix) with ESMTP id 60DECBD247 for ; Fri, 31 Jan 2003 09:23:42 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <3E37DE0C.8090206@redback.com> <067801c2c910$ba7fe9c0$81c802c0@alok> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E3AB0C9.2070708@redback.com> Date: Fri, 31 Jan 2003 12:22:17 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Working Group Last Call for draft-ietf-ospf-hitless-restart-05.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi Alok, Let me attempt to address your points inline below. alok wrote: > Hi, > > there is something which I would appreciate if someone could clarify > > > 1. what is "restarting" and what is "after restarting" state? essentially my > concern being: > > page 2 > > (2) The restarting router runs its OSPF routing calculations, as > specified in Section 16 of [1]. This is necessary to > return any OSPF virtual links to operation. However, the > restarting router does *not* install OSPF routes into the > system's forwarding table(s), instead relying on the > forwarding entries that it had installed prior to the > restart. > > what does point 2 mean? Conceptually, you have to have an OSPF route table that is independent of the forwarding table(s). Virtual links will be marked UP as soon as there is a transit area route to the virtual link's endpoint ABR. A restarting router cannot update the forwarding table until it exits graceful restart. > > again mentioned on 2.3 point 3, it says after it has "exited restart state" > the routes will be put in the FT. > > what defines hitless restart time is the "grace period" which means "the > router wont originate LSAs till LSRefreshtimer" : > In order to avoid > the restarting router's LSAs from aging out, the grace period > should not exceed LSRefreshTime (1800 second) The grace interval expiring is only one of many reasons to exit graceful restart. > > > .....which anyways is the default operation if there is no topology change. > (i hope I am right here) > > doing it this way implies that if there is a topology change elsewhere when > the router is down, we would wait till the "old LSAs the router was > orginating" become stale......to update the FT. Nope - if we receive a copy of our LSA that is inconsistent with the pre-restart copy we will exit graceful restart immediately. See 2.2 (2). > > so why "wait" for that time at all before updating the FT > > would making the simple test be "grace period is over as soon as OSPF > reestablishes adjacencies and time passed since the begininning of restart > is less than MinLSinterval"..hence start populating the FT with the new > entries.... An OSPF router will exit graceful restart prior to the grace interval if it establishes all its prior adjacencies. See 2.2 (1). There are also some implementation dependent wait condition relating to route redistribution but those are beyond the scope of this document. > > is my interpretation correct? > > -rgds > Alok > > > > ----- Original Message ----- > From: Acee Lindem > To: > Sent: Wednesday, January 29, 2003 7:28 PM > Subject: Working Group Last Call for draft-ietf-ospf-hitless-restart-05.txt > > > >>This is the start of a Working Group last call for >>draft-ietf-ospf-hitless-restart-05.txt, OSPF Hitless Restart. >>All comments must be sent to the OSPF list by Friday, >>February 8th, 2003. >> >>A URL for this Internet-Draft is: >>http://www.ietf.org/internet-drafts/draft-ietf-ospf-hitless-restart-05.txt >> >>My previous list posting on this WG last call was lost or >>filtering. My apologies if this is a duplicate. >> >>Thanks, >>Acee & Rohit >>-- >>Acee >> > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Fri Jan 31 12:27:52 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12955 for ; Fri, 31 Jan 2003 12:27:52 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.008C2E76@cherry.ease.lsoft.com>; Fri, 31 Jan 2003 12:31:14 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 590096 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 31 Jan 2003 12:31:14 -0500 Received: from 64.106.140.220 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 31 Jan 2003 12:31:14 -0500 Received: from www.apara.com (localhost.localdomain [127.0.0.1]) by www.apara.com (8.11.6/8.11.6) with ESMTP id h0VHoaQ17149 for ; Fri, 31 Jan 2003 23:20:36 +0530 Received: from alok ([203.124.140.100]) (authenticated) by www.apara.com (8.11.6/8.11.6) with ESMTP id h0VHoXt17143; Fri, 31 Jan 2003 23:20:34 +0530 References: <3E37DE0C.8090206@redback.com> <067801c2c910$ba7fe9c0$81c802c0@alok> <3E3AB0C9.2070708@redback.com> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Message-ID: <0c9501c2c94e$d595edc0$81c802c0@alok> Date: Fri, 31 Jan 2003 22:59:52 +0530 Reply-To: Mailing List Sender: Mailing List From: alok Subject: Re: Working Group Last Call for draft-ietf-ospf-hitless-restart-05.txt Comments: cc: "d.deepak" To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list so As MR deepak said ccing him no neighbour router suppout for this, (even one) nomore owrking of draft? ciao alok ----- Original Message ----- From: Acee Lindem To: Sent: Friday, January 31, 2003 10:52 PM Subject: Re: Working Group Last Call for draft-ietf-ospf-hitless-restart-05.txt > Hi Alok, > > Let me attempt to address your points inline below. > > alok wrote: > > Hi, > > > > there is something which I would appreciate if someone could clarify > > > > > > 1. what is "restarting" and what is "after restarting" state? essentially my > > concern being: > > > > page 2 > > > > (2) The restarting router runs its OSPF routing calculations, as > > specified in Section 16 of [1]. This is necessary to > > return any OSPF virtual links to operation. However, the > > restarting router does *not* install OSPF routes into the > > system's forwarding table(s), instead relying on the > > forwarding entries that it had installed prior to the > > restart. > > > > what does point 2 mean? > > Conceptually, you have to have an OSPF route table that is independent > of the forwarding table(s). Virtual links will be marked UP as soon as there > is a transit area route to the virtual link's endpoint ABR. A restarting > router cannot update the forwarding table until it exits graceful restart. > > > > > again mentioned on 2.3 point 3, it says after it has "exited restart state" > > the routes will be put in the FT. > > > > what defines hitless restart time is the "grace period" which means "the > > router wont originate LSAs till LSRefreshtimer" : > > In order to avoid > > the restarting router's LSAs from aging out, the grace period > > should not exceed LSRefreshTime (1800 second) > > The grace interval expiring is only one of many reasons to exit graceful > restart. > > > > > > > .....which anyways is the default operation if there is no topology change. > > (i hope I am right here) > > > > doing it this way implies that if there is a topology change elsewhere when > > the router is down, we would wait till the "old LSAs the router was > > orginating" become stale......to update the FT. > > Nope - if we receive a copy of our LSA that is inconsistent with the > pre-restart copy we will exit graceful restart immediately. See 2.2 (2). > > > > > so why "wait" for that time at all before updating the FT > > > > would making the simple test be "grace period is over as soon as OSPF > > reestablishes adjacencies and time passed since the begininning of restart > > is less than MinLSinterval"..hence start populating the FT with the new > > entries.... > > An OSPF router will exit graceful restart prior to the grace interval if > it establishes all its prior adjacencies. See 2.2 (1). There are also > some implementation dependent wait condition relating to route redistribution > but those are beyond the scope of this document. > > > > > > is my interpretation correct? > > > > -rgds > > Alok > > > > > > > > ----- Original Message ----- > > From: Acee Lindem > > To: > > Sent: Wednesday, January 29, 2003 7:28 PM > > Subject: Working Group Last Call for draft-ietf-ospf-hitless-restart-05.txt > > > > > > > >>This is the start of a Working Group last call for > >>draft-ietf-ospf-hitless-restart-05.txt, OSPF Hitless Restart. > >>All comments must be sent to the OSPF list by Friday, > >>February 8th, 2003. > >> > >>A URL for this Internet-Draft is: > >>http://www.ietf.org/internet-drafts/draft-ietf-ospf-hitless-restart-05.txt > >> > >>My previous list posting on this WG last call was lost or > >>filtering. My apologies if this is a duplicate. > >> > >>Thanks, > >>Acee & Rohit > >>-- > >>Acee > >> > > > > > > > -- > Acee > From owner-ospf@DISCUSS.MICROSOFT.COM Fri Jan 31 12:52:39 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13608 for ; Fri, 31 Jan 2003 12:52:38 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.008C2F14@cherry.ease.lsoft.com>; Fri, 31 Jan 2003 12:56:12 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 590197 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 31 Jan 2003 12:56:11 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 31 Jan 2003 12:56:11 -0500 Received: from redback.com (login003.redback.com [155.53.12.55]) by prattle.redback.com (Postfix) with ESMTP id 4BADE3EE740 for ; Fri, 31 Jan 2003 09:56:10 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <3E37DE0C.8090206@redback.com> <067801c2c910$ba7fe9c0$81c802c0@alok> <3E3AB0C9.2070708@redback.com> <0c9501c2c94e$d595edc0$81c802c0@alok> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E3AB865.7080906@redback.com> Date: Fri, 31 Jan 2003 12:54:45 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Working Group Last Call for draft-ietf-ospf-hitless-restart-05.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit alok wrote: > so As MR deepak said > ccing him > > no neighbour router suppout for this, (even one) nomore owrking of draft? Almost - non-support from any neighbor that was fully adjacent prior to restart will result in the restarting router aborting graceful restart when it detects a discrepancy in the router's intra-area LSAs (i.e., type 1 or 2). Publishing this draft as an RFC will go along ways towards promoting universal support. > > > ciao > alok > > > ----- Original Message ----- > From: Acee Lindem > To: > Sent: Friday, January 31, 2003 10:52 PM > Subject: Re: Working Group Last Call for > draft-ietf-ospf-hitless-restart-05.txt > > > >>Hi Alok, >> >>Let me attempt to address your points inline below. >> >>alok wrote: >> >>>Hi, >>> >>>there is something which I would appreciate if someone could clarify >>> >>> >>>1. what is "restarting" and what is "after restarting" state? >> > essentially my > >>>concern being: >>> >>>page 2 >>> >>> (2) The restarting router runs its OSPF routing calculations, as >>> specified in Section 16 of [1]. This is necessary to >>> return any OSPF virtual links to operation. However, the >>> restarting router does *not* install OSPF routes into the >>> system's forwarding table(s), instead relying on the >>> forwarding entries that it had installed prior to the >>> restart. >>> >>>what does point 2 mean? >> >>Conceptually, you have to have an OSPF route table that is independent >>of the forwarding table(s). Virtual links will be marked UP as soon as > > there > >>is a transit area route to the virtual link's endpoint ABR. A restarting >>router cannot update the forwarding table until it exits graceful restart. >> >> >>>again mentioned on 2.3 point 3, it says after it has "exited restart >> > state" > >>>the routes will be put in the FT. >>> >>>what defines hitless restart time is the "grace period" which means "the >>>router wont originate LSAs till LSRefreshtimer" : >>>In order to avoid >>> the restarting router's LSAs from aging out, the grace period >>> should not exceed LSRefreshTime (1800 second) >> >>The grace interval expiring is only one of many reasons to exit graceful >>restart. >> >> >>> >>>.....which anyways is the default operation if there is no topology >> > change. > >>>(i hope I am right here) >>> >>>doing it this way implies that if there is a topology change elsewhere >> > when > >>>the router is down, we would wait till the "old LSAs the router was >>>orginating" become stale......to update the FT. >> >>Nope - if we receive a copy of our LSA that is inconsistent with the >>pre-restart copy we will exit graceful restart immediately. See 2.2 (2). >> >> >>>so why "wait" for that time at all before updating the FT >>> >>>would making the simple test be "grace period is over as soon as OSPF >>>reestablishes adjacencies and time passed since the begininning of >> > restart > >>>is less than MinLSinterval"..hence start populating the FT with the new >>>entries.... >> >>An OSPF router will exit graceful restart prior to the grace interval if >>it establishes all its prior adjacencies. See 2.2 (1). There are also >>some implementation dependent wait condition relating to route > > redistribution > >>but those are beyond the scope of this document. >> >> >> >>>is my interpretation correct? >>> >>>-rgds >>>Alok >>> >>> >>> >>>----- Original Message ----- >>>From: Acee Lindem >>>To: >>>Sent: Wednesday, January 29, 2003 7:28 PM >>>Subject: Working Group Last Call for >> > draft-ietf-ospf-hitless-restart-05.txt > >>> >>> >>>>This is the start of a Working Group last call for >>>>draft-ietf-ospf-hitless-restart-05.txt, OSPF Hitless Restart. >>>>All comments must be sent to the OSPF list by Friday, >>>>February 8th, 2003. >>>> >>>>A URL for this Internet-Draft is: >>> >>>http://www.ietf.org/internet-drafts/draft-ietf-ospf-hitless-restart-05.txt >>> >>>>My previous list posting on this WG last call was lost or >>>>filtering. My apologies if this is a duplicate. >>>> >>>>Thanks, >>>>Acee & Rohit >>>>-- >>>>Acee >>>> >>> >>> >> >>-- >>Acee >> > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Fri Jan 31 13:11:24 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14259 for ; Fri, 31 Jan 2003 13:11:24 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.008C2F73@cherry.ease.lsoft.com>; Fri, 31 Jan 2003 13:14:51 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 590293 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 31 Jan 2003 13:14:51 -0500 Received: from 64.106.140.220 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 31 Jan 2003 13:14:51 -0500 Received: from www.apara.com (localhost.localdomain [127.0.0.1]) by www.apara.com (8.11.6/8.11.6) with ESMTP id h0VIYDQ17918 for ; Sat, 1 Feb 2003 00:04:13 +0530 Received: from alok ([203.124.140.100]) (authenticated) by www.apara.com (8.11.6/8.11.6) with ESMTP id h0VIYBt17912; Sat, 1 Feb 2003 00:04:12 +0530 References: <3E37DE0C.8090206@redback.com> <067801c2c910$ba7fe9c0$81c802c0@alok> <3E3AB0C9.2070708@redback.com> <0c9501c2c94e$d595edc0$81c802c0@alok> <3E3AB865.7080906@redback.com> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Message-ID: <0e5301c2c954$ed5c9a20$81c802c0@alok> Date: Fri, 31 Jan 2003 23:46:34 +0530 Reply-To: Mailing List Sender: Mailing List From: alok Subject: Re: Working Group Last Call for draft-ietf-ospf-hitless-restart-05.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list > alok wrote: > > so As MR deepak said > > ccing him > > > > no neighbour router suppout for this, (even one) nomore owrking of draft? > > Almost - non-support from any neighbor that was fully adjacent prior to > restart will result in the restarting router aborting graceful restart when > it detects a discrepancy in the router's intra-area LSAs (i.e., type 1 or > 2). > and that means : as the draft says....the "non helper" neighbour screws the guy who supports the "helper"...why does life sound better on a black board? so lets dump those "routers"?? who dont rely supporting this?...........?? uh oh>? one screw up can one reboot in :routerdeadinterval"......and why not? my next RFC says .....make it to 60seconds?? possible? yes..........if u "big" guys pass it ;o) From owner-ospf@DISCUSS.MICROSOFT.COM Fri Jan 31 16:40:39 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19782 for ; Fri, 31 Jan 2003 16:40:39 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.008C445B@cherry.ease.lsoft.com>; Fri, 31 Jan 2003 16:44:11 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 591516 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 31 Jan 2003 16:44:10 -0500 Received: from 171.71.163.11 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 31 Jan 2003 16:34:09 -0500 Received: from irp-view7.cisco.com (irp-view7.cisco.com [171.70.65.144]) by sj-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0VLY9SQ001300 for ; Fri, 31 Jan 2003 13:34:09 -0800 (PST) Received: from localhost (akr@localhost) by irp-view7.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id NAA06981 for ; Fri, 31 Jan 2003 13:34:09 -0800 (PST) X-Authentication-Warning: irp-view7.cisco.com: akr owned process doing -bs References: <3E39DF3F.5080201@redback.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Fri, 31 Jan 2003 13:34:09 -0800 Reply-To: Mailing List Sender: Mailing List From: Abhay Roy Subject: Re: OSPF IGP Capabilities Draft To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3E39DF3F.5080201@redback.com> Precedence: list Acee, One of the questions raised was, why do we need to advertise these capabilities? I am glad to see that, there is at least one useful application (as in PCSD). I still have those reservations about the usefulness of many other 'capabilities' this document describes. IMHO, if the receivers of these capabilities are just going to display it in a 'show' command, we should NOT specify them in this document. Regards, -Roy- On 01/30/03-0500 at 9:28pm, Acee Lindem writes: > As many of you recall, we've discussed this draft at both > the Yokohama and Atlanta OSPF WG meetings. I wasn't in Yokohama > but apparently there were some present who voiced reservations > with the draft. In Atlanta, there wasn't a lot of discussion (other > than strong support from the authors ;^). We agreed to discuss this > draft further on the OSPF list. > > Are there still people who have reservations with the draft? > > http://www.ietf.org/internet-drafts/draft-raggarwa-igp-cap-01.txt > > [Speaking as a WG member] > > I think the draft is a natural mechanism for advertising new OSPF > capabilities now that the LSA option bits have been exhausted. > We've already extended OSPF to support traffic engineering (TE) > information and this mechanism is slated to be used for propagating > an OSPF router's ability to act as an MPLS TE path computation > server (PCS). > > Thanks, > -- > Acee >