From owner-ospf@DISCUSS.MICROSOFT.COM Sun Dec 1 06:37:24 2002 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 GAA03021 for ; Sun, 1 Dec 2002 06:37:24 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00808AD8@cherry.ease.lsoft.com>; 1 Dec 2002 6:40:10 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 422647 for OSPF@DISCUSS.MICROSOFT.COM; Sun, 1 Dec 2002 06:40:10 -0500 Received: from 171.68.227.73 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Sun, 1 Dec 2002 06:40:10 -0500 Received: from smirtoraw2k01 (dhcp-144-254-56-89.cisco.com [144.254.56.89]) by fire.cisco.com (8.11.6+Sun/8.8.8) with ESMTP id gB1Be8O16367; Sun, 1 Dec 2002 03:40:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: <006a01c2992e$668ac130$5938fe90@amer.cisco.com> Date: Sun, 1 Dec 2002 03:40:06 -0800 Reply-To: Mailing List Sender: Mailing List From: Sina Mirtorabi Subject: Re: OSPFv3 nexthop Comments: To: Yasuhiro Ohara To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <20021201.034009.123556283.yasu@sfc.wide.ad.jp> Precedence: list Content-Transfer-Encoding: 7bit Yasu, > > sina> having global address in Link-LSA is irrelevant to next hop > sina> calculation, the fact of carrying global IPv6 address > in Link-LSA > sina> is just related to announcing all global Ipv6 address of a > sina> multi-access link to DR so that it will announce them in its > sina> intra-area-prefix LSA > sina> > sina> Link-local address is the only address to be always > available ( as > sina> Acee said ) therefore this address can always be used to reach > sina> your nexthop and you should not need any other address > even a node > sina> can have multiple IPv6 address Yasu> Having a global address in Link-LSA (specifically in Yasu> 'Link-local Interface Address' field) is *not* irrelevant. It Yasu> will be used as the actual nexthop in SPF calculation. First of all as its name says "Link-local Interface Address" field contain a link local address and *Not* a global IPv6 address, it is clearly mentioned in the RFC --- Link-local Interface Address The originating router's link-local interface address on the link. ... Link-LSAs have three purposes: 1) they provide the router's link-local address to all other routers attached to the link and 2) they inform other routers attached to the link of a list of IPv6 prefixes to associate with the link and 3) they allow the router to assert a collection of Options bits to associate with the Network-LSA that will be originated for the link. ... A router learns the link-local addresses of all other routers attached to its links, and uses these addresses as next hop information during packet forwarding. ---- I think it is clear enough from the above that the global address in the Link-LSA is used for announcing those prefix to the DR and therefore is irrelevant to nexthop calculation which use only link-local address;-) Last we do not really need Link-LSA for nexthop calculation ( as it is mentioned in the RFC ) except for NBMA, since we would learn them through Hello reception and the source IPv6 address of this packet *is* a link-local address Yasu> It is possible for an implementation to recognize a Link-LSA Yasu> which has a global-address in 'Link-local Interface Address' Yasu> field as an invalid Link-LSA. It is just because RFC2740 Yasu> describes that way (or the field name indicates that way). I don't think so, the filed name says clearly what is the value of this field otherwise it would have stated that it can be an IPv6 address Yasu> I agree that if OSPFv3 implementation allows, having global Yasu> address as nexthop will not be a problem. Yasu> Route table lookup may ensue further to find link-local Yasu> address for it, or NDP(or some other L2-L3 address mapping Yasu> mechanism) will work directly on the global address to derive Yasu> its corresponding L2 address. The question is Why should I ever need to set the nexthop to a global Ipv6 address ? If you tell me that then I would agree that RFC need to mention that the nexthop can be set to a global IPv6 address. After all you want to send your packet to your _nexthop_ so your neighbor link-local address is the Ipv6 address that is always available and least likely to change Sina > sina> If you are referring to FA setting, although if it is > necessary to > sina> have a global Ipv6 address for FA setting this address is only > sina> used to forward a packet to, but this does Not mean that the > sina> nexthop is the FA. A router while trying to install a > route to the > sina> external with FA set needs to just know its nexthop > which would be > sina> a link-local address ( even if the ASBR setting the FA > is directly > sina> connected to this router ) > > Agree, FA will be used to derive actual nexthop, which will > be a link-local address in most cases. > > regards, > yasu > From owner-ospf@DISCUSS.MICROSOFT.COM Mon Dec 2 04:19:06 2002 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 EAA08570 for ; Mon, 2 Dec 2002 04:19:05 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.0080B9CA@cherry.ease.lsoft.com>; Mon, 2 Dec 2002 4:21:50 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 426011 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 2 Dec 2002 04:21:50 -0500 Received: from 203.178.142.130 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 2 Dec 2002 04:21:50 -0500 Received: from localhost (page.sfc.wide.ad.jp [203.178.143.89]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 638D860A25; Mon, 2 Dec 2002 18:21:48 +0900 (JST) References: <20021201.034009.123556283.yasu@sfc.wide.ad.jp> <006a01c2992e$668ac130$5938fe90@amer.cisco.com> X-Mailer: Mew version 2.1 on XEmacs 21.1.14 (Cuyahoga Valley) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20021202.182147.123555327.yasu@sfc.wide.ad.jp> Date: Mon, 2 Dec 2002 18:21:47 +0900 Reply-To: Mailing List Sender: Mailing List From: Yasuhiro Ohara Subject: Re: OSPFv3 nexthop Comments: To: sina@cisco.com To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <006a01c2992e$668ac130$5938fe90@amer.cisco.com> Precedence: list Content-Transfer-Encoding: 7bit sina> First of all as its name says "Link-local Interface Address" field sina> contain a link local address and *Not* a global IPv6 address, it is sina> clearly mentioned in the RFC Okay, I thought the original question was "Why do we restrict next-hop to be link-local ?" (interpret by me as "What will happen when we use global address as nexthop by advertising a global-address within Link-local Interface Address field in Link-LSA ?") sina> The question is Why should I ever need to set the nexthop to a global sina> Ipv6 address ? If you tell me that then I would agree that RFC need to sina> mention that the nexthop can be set to a global IPv6 address. Yes, we don't need nexthops to be global, as far as I know, even in the FA case. I wanted to mention that technically nexthop address advertised with Link-LSA (thus used as actual nexthop) could be global address. I agree that it is simpler to restrict nexthop to be link-local address, and I agree rest of your message. regards, yasu From owner-ospf@DISCUSS.MICROSOFT.COM Mon Dec 2 07:13:05 2002 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 HAA11186 for ; Mon, 2 Dec 2002 07:13:05 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.0080BDB4@cherry.ease.lsoft.com>; Mon, 2 Dec 2002 7:15:52 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 426985 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 2 Dec 2002 07:15:52 -0500 Received: from 12.27.183.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 2 Dec 2002 07:15:52 -0500 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <4B0HRFS5>; Mon, 2 Dec 2002 07:15:47 -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, 2 Dec 2002 07:17:53 -0500 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: OSPFv3 nexthop To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Yasu/Sina/Acee, Thanks for the discussion. Firstly let me explain the three statements Sina has quoted from the draft(which I misconstrued to mean the same Sina did earlier). Link-local Interface Address The originating router's link-local interface address on the link. Though this clearly means the link LSA can have only link-local address in the Link-local Interface address field, global/site local prefixes can always be contained in the Address prefix field in the same LSA. There is nothing that prevents it(infact because we are using the term "link-local" for the constrained field, not using the term for the prefix suggests clearly that non link-locals could be used in prefixes. Link-LSAs have three purposes: 1) they provide the router's link-local address to all other routers attached to the link and 2) they inform other routers attached to the link of a list of IPv6 prefixes to associate with the link and 3) they allow the router to assert a collection of Options bits to associate with the Network-LSA that will be originated for the link. This nowhere states that a router cannot have non-link-local addresses in "Link LSA". Because the link-local address field is compulsary the statement 1) is correct. The point 2) clearly states that it can inform of other addresses too, by not explicitly prefixing the term link-local. A router learns the link-local addresses of all other routers attached to its links, and uses these addresses as next hop information during packet forwarding. This statement also does not anyway state that non-link local prefixes cannot be used, it only states that link-locals are used for nexthop calculation. The requirement that I was talking about in my earlier mail wasn't about FA. I was talking about a case where BGP uses the IGP nexthop to advertize in its routes, in which case we will require a non-local scope address (and as Acee put it third-party nexthop) Thanks, Vishwas -----Original Message----- From: Sina Mirtorabi [mailto:sina@CISCO.COM] Sent: Sunday, December 01, 2002 5:10 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: OSPFv3 nexthop Yasu, > > sina> having global address in Link-LSA is irrelevant to next hop > sina> calculation, the fact of carrying global IPv6 address > in Link-LSA > sina> is just related to announcing all global Ipv6 address of a > sina> multi-access link to DR so that it will announce them in its > sina> intra-area-prefix LSA > sina> > sina> Link-local address is the only address to be always > available ( as > sina> Acee said ) therefore this address can always be used to reach > sina> your nexthop and you should not need any other address > even a node > sina> can have multiple IPv6 address Yasu> Having a global address in Link-LSA (specifically in Yasu> 'Link-local Interface Address' field) is *not* irrelevant. It Yasu> will be used as the actual nexthop in SPF calculation. First of all as its name says "Link-local Interface Address" field contain a link local address and *Not* a global IPv6 address, it is clearly mentioned in the RFC --- Link-local Interface Address The originating router's link-local interface address on the link. ... Link-LSAs have three purposes: 1) they provide the router's link-local address to all other routers attached to the link and 2) they inform other routers attached to the link of a list of IPv6 prefixes to associate with the link and 3) they allow the router to assert a collection of Options bits to associate with the Network-LSA that will be originated for the link. ... A router learns the link-local addresses of all other routers attached to its links, and uses these addresses as next hop information during packet forwarding. ---- I think it is clear enough from the above that the global address in the Link-LSA is used for announcing those prefix to the DR and therefore is irrelevant to nexthop calculation which use only link-local address;-) Last we do not really need Link-LSA for nexthop calculation ( as it is mentioned in the RFC ) except for NBMA, since we would learn them through Hello reception and the source IPv6 address of this packet *is* a link-local address Yasu> It is possible for an implementation to recognize a Link-LSA Yasu> which has a global-address in 'Link-local Interface Address' Yasu> field as an invalid Link-LSA. It is just because RFC2740 Yasu> describes that way (or the field name indicates that way). I don't think so, the filed name says clearly what is the value of this field otherwise it would have stated that it can be an IPv6 address Yasu> I agree that if OSPFv3 implementation allows, having global Yasu> address as nexthop will not be a problem. Yasu> Route table lookup may ensue further to find link-local Yasu> address for it, or NDP(or some other L2-L3 address mapping Yasu> mechanism) will work directly on the global address to derive Yasu> its corresponding L2 address. The question is Why should I ever need to set the nexthop to a global Ipv6 address ? If you tell me that then I would agree that RFC need to mention that the nexthop can be set to a global IPv6 address. After all you want to send your packet to your _nexthop_ so your neighbor link-local address is the Ipv6 address that is always available and least likely to change Sina > sina> If you are referring to FA setting, although if it is > necessary to > sina> have a global Ipv6 address for FA setting this address is only > sina> used to forward a packet to, but this does Not mean that the > sina> nexthop is the FA. A router while trying to install a > route to the > sina> external with FA set needs to just know its nexthop > which would be > sina> a link-local address ( even if the ASBR setting the FA > is directly > sina> connected to this router ) > > Agree, FA will be used to derive actual nexthop, which will > be a link-local address in most cases. > > regards, > yasu > From owner-ospf@DISCUSS.MICROSOFT.COM Mon Dec 2 08:33:09 2002 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 IAA13910 for ; Mon, 2 Dec 2002 08:33:08 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.0080BF1F@cherry.ease.lsoft.com>; Mon, 2 Dec 2002 8:35:55 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 427116 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 2 Dec 2002 08:35:55 -0500 Received: from 171.68.227.73 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 2 Dec 2002 08:35:55 -0500 Received: from smirtoraw2k01 (dhcp-144-254-56-89.cisco.com [144.254.56.89]) by fire.cisco.com (8.11.6+Sun/8.8.8) with ESMTP id gB2DZrO05987 for ; Mon, 2 Dec 2002 05:35:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: <00bd01c29a07$bc1f1f40$5938fe90@amer.cisco.com> Date: Mon, 2 Dec 2002 05:35:51 -0800 Reply-To: Mailing List Sender: Mailing List From: Sina Mirtorabi Subject: Re: OSPFv3 nexthop To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit Vishwas, In short : "nothing prevent an implementation to set the nexthop to any IPv6 address in Link-LSA" even RFC mention that nexthop is a link-local address In a bit longer ;-) Announcing a global IPv6 address for BGP is more a BGP issue than OSPF, when I redistribute OSPF into BGP and I need to use a third party nexthop for BGP I can 1) change my OSPF nexthop to global IPv6 address in the Link-LSA and announce this address for BGP nexthop 2) Look for a global IPv6 address belonging to my OSPF neighbor and set BGP nexthop to this value without changing OSPF nexthop ( which is link-local ). This is more an implementation matter .. I still do not see where we need to change the nexthop to a global IPv6 address for OSPF use ;-) I would still argue that global IPv6 address in Link-LSA is for announcing to DR, and link-local address is the only address needed for nexthop although nothing prevent an implementation to pick up any IPv6 address in the Link-LSA as nexthop... Sina > > Yasu/Sina/Acee, > > Thanks for the discussion. > > Firstly let me explain the three statements Sina has quoted > from the draft(which I misconstrued to mean the same Sina did > earlier). > > Link-local Interface Address > The originating router's link-local interface address on the > link. > > Though this clearly means the link LSA can have only > link-local address in the Link-local Interface address field, > global/site local prefixes can always be contained in the > Address prefix field in the same LSA. There is nothing that > prevents it(infact because we are using the term "link-local" > for the constrained field, not using the term for the prefix > suggests clearly that non link-locals could be used in prefixes. > > Link-LSAs have three purposes: 1) they > provide the router's link-local address to all other > routers attached > to the link and 2) they inform other routers attached to > the link of > a list of IPv6 prefixes to associate with the link and 3) > they allow > the router to assert a collection of Options bits to associate with > the Network-LSA that will be originated for the link. > > This nowhere states that a router cannot have non-link-local > addresses in "Link LSA". Because the link-local address field > is compulsary the statement > 1) is correct. The point 2) clearly states that it can inform > of other addresses too, by not explicitly prefixing the term > link-local. > > A router learns the link-local addresses of all other > routers attached to its links, and uses these addresses as next hop > information during packet forwarding. > > This statement also does not anyway state that non-link local > prefixes cannot be used, it only states that link-locals are > used for nexthop calculation. > > The requirement that I was talking about in my earlier mail > wasn't about FA. I was talking about a case where BGP uses > the IGP nexthop to advertize in its routes, in which case we > will require a non-local scope address (and as Acee put it > third-party nexthop) > > Thanks, > Vishwas > > > -----Original Message----- > From: Sina Mirtorabi [mailto:sina@CISCO.COM] > Sent: Sunday, December 01, 2002 5:10 PM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Re: OSPFv3 nexthop > > > Yasu, > > > > > > sina> having global address in Link-LSA is irrelevant to next hop > > sina> calculation, the fact of carrying global IPv6 address > > in Link-LSA > > sina> is just related to announcing all global Ipv6 address of a > > sina> multi-access link to DR so that it will announce them in its > > sina> intra-area-prefix LSA > > sina> > > sina> Link-local address is the only address to be always > > available ( as > > sina> Acee said ) therefore this address can always be used > to reach > > sina> your nexthop and you should not need any other address > > even a node > > sina> can have multiple IPv6 address > > Yasu> Having a global address in Link-LSA (specifically in > 'Link-local > Yasu> Interface Address' field) is *not* irrelevant. It will > be used as > Yasu> the actual nexthop in SPF calculation. > > First of all as its name says "Link-local Interface Address" > field contain a link local address and *Not* a global IPv6 > address, it is clearly mentioned in the RFC > > --- > Link-local Interface Address > The originating router's link-local interface address on the > link. > > ... > > Link-LSAs have three purposes: 1) they > provide the router's link-local address to all other > routers attached > to the link and 2) they inform other routers attached to > the link of > a list of IPv6 prefixes to associate with the link and 3) > they allow > the router to assert a collection of Options bits to associate with > the Network-LSA that will be originated for the link. > > ... > > A router learns the link-local addresses of all other > routers attached to its links, and uses these addresses as next hop > information during packet forwarding. > > ---- > > I think it is clear enough from the above that the global > address in the Link-LSA is used for announcing those prefix > to the DR and therefore is irrelevant to nexthop calculation > which use only link-local address;-) > > Last we do not really need Link-LSA for nexthop calculation ( > as it is mentioned in the RFC ) except for NBMA, since we > would learn them through Hello reception and the source IPv6 > address of this packet *is* a link-local address > > > Yasu> It is possible for an implementation to recognize a > Link-LSA which > Yasu> has a global-address in 'Link-local Interface Address' > field as an > Yasu> invalid Link-LSA. It is just because RFC2740 describes that way > Yasu> (or the field name indicates that way). > > I don't think so, the filed name says clearly what is the > value of this field otherwise it would have stated that it > can be an IPv6 address > > Yasu> I agree that if OSPFv3 implementation allows, having global > Yasu> address as nexthop will not be a problem. > > Yasu> Route table lookup may ensue further to find link-local address > Yasu> for it, or NDP(or some other L2-L3 address mapping > Yasu> mechanism) will work directly on the global address to > derive its > Yasu> corresponding L2 address. > > The question is Why should I ever need to set the nexthop to > a global Ipv6 address ? If you tell me that then I would > agree that RFC need to mention that the nexthop can be set to > a global IPv6 address. > > After all you want to send your packet to your _nexthop_ so > your neighbor link-local address is the Ipv6 address that is > always available and least likely to change > > Sina > > > > sina> If you are referring to FA setting, although if it is > > necessary to > > sina> have a global Ipv6 address for FA setting this > address is only > > sina> used to forward a packet to, but this does Not mean that the > > sina> nexthop is the FA. A router while trying to install a > > route to the > > sina> external with FA set needs to just know its nexthop > > which would be > > sina> a link-local address ( even if the ASBR setting the FA > > is directly > > sina> connected to this router ) > > > > Agree, FA will be used to derive actual nexthop, which will be a > > link-local address in most cases. > > > > regards, > > yasu > > > From owner-ospf@DISCUSS.MICROSOFT.COM Mon Dec 2 08:56:46 2002 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 IAA14894 for ; Mon, 2 Dec 2002 08: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 <22.0080BF53@cherry.ease.lsoft.com>; Mon, 2 Dec 2002 8:59:34 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 427170 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 2 Dec 2002 08:59:34 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 2 Dec 2002 08:59:34 -0500 Received: from redback.com (login003.redback.com [155.53.12.55]) by prattle.redback.com (Postfix) with ESMTP id DD23D1C3571 for ; Mon, 2 Dec 2002 05:58:54 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <00bd01c29a07$bc1f1f40$5938fe90@amer.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3DEB67B3.5020508@redback.com> Date: Mon, 2 Dec 2002 09:01:23 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: OSPFv3 nexthop To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Sina Mirtorabi wrote: > Vishwas, > > In short : "nothing prevent an implementation to set the nexthop to any > IPv6 address in Link-LSA" even RFC mention that nexthop is a link-local > address > > In a bit longer ;-) > > Announcing a global IPv6 address for BGP is more a BGP issue than OSPF, > when I redistribute OSPF into BGP and I need to use a third party > nexthop for BGP I can > > 1) change my OSPF nexthop to global IPv6 address in the Link-LSA and > announce this address for BGP nexthop > > 2) Look for a global IPv6 address belonging to my OSPF neighbor and set > BGP nexthop to this value without changing OSPF nexthop ( which is > link-local ). > > This is more an implementation matter .. I still do not see where we > need to change the nexthop to a global IPv6 address for OSPF use ;-) I agree here. OSPFv3 should not install a global nexthop just to make BGP's job easier when determining whether or not a third party nexthop can be advertised. How BGP does this is an implementation matter. > > I would still argue that global IPv6 address in Link-LSA is for > announcing to DR, and link-local address is the only address needed for > nexthop although nothing prevent an implementation to pick up any IPv6 > address in the Link-LSA as nexthop... > > Sina > > > >>Yasu/Sina/Acee, >> >>Thanks for the discussion. >> >>Firstly let me explain the three statements Sina has quoted >>from the draft(which I misconstrued to mean the same Sina did >>earlier). >> >> Link-local Interface Address >> The originating router's link-local interface address on the >> link. >> >>Though this clearly means the link LSA can have only >>link-local address in the Link-local Interface address field, >>global/site local prefixes can always be contained in the >>Address prefix field in the same LSA. There is nothing that >>prevents it(infact because we are using the term "link-local" >>for the constrained field, not using the term for the prefix >>suggests clearly that non link-locals could be used in prefixes. >> >> Link-LSAs have three purposes: 1) they >> provide the router's link-local address to all other >>routers attached >> to the link and 2) they inform other routers attached to >>the link of >> a list of IPv6 prefixes to associate with the link and 3) >>they allow >> the router to assert a collection of Options bits to associate with >> the Network-LSA that will be originated for the link. >> >>This nowhere states that a router cannot have non-link-local >>addresses in "Link LSA". Because the link-local address field >>is compulsary the statement >>1) is correct. The point 2) clearly states that it can inform >>of other addresses too, by not explicitly prefixing the term >>link-local. >> >> A router learns the link-local addresses of all other >> routers attached to its links, and uses these addresses as next hop >> information during packet forwarding. >> >>This statement also does not anyway state that non-link local >>prefixes cannot be used, it only states that link-locals are >>used for nexthop calculation. > > > > >>The requirement that I was talking about in my earlier mail >>wasn't about FA. I was talking about a case where BGP uses >>the IGP nexthop to advertize in its routes, in which case we >>will require a non-local scope address (and as Acee put it >>third-party nexthop) >> >>Thanks, >>Vishwas >> >> >>-----Original Message----- >>From: Sina Mirtorabi [mailto:sina@CISCO.COM] >>Sent: Sunday, December 01, 2002 5:10 PM >>To: OSPF@DISCUSS.MICROSOFT.COM >>Subject: Re: OSPFv3 nexthop >> >> >>Yasu, >> >> >> >>>sina> having global address in Link-LSA is irrelevant to next hop >>>sina> calculation, the fact of carrying global IPv6 address >>>in Link-LSA >>>sina> is just related to announcing all global Ipv6 address of a >>>sina> multi-access link to DR so that it will announce them in its >>>sina> intra-area-prefix LSA >>>sina> >>>sina> Link-local address is the only address to be always >>>available ( as >>>sina> Acee said ) therefore this address can always be used >> >>to reach >> >>>sina> your nexthop and you should not need any other address >>>even a node >>>sina> can have multiple IPv6 address >> >>Yasu> Having a global address in Link-LSA (specifically in >>'Link-local >>Yasu> Interface Address' field) is *not* irrelevant. It will >>be used as >>Yasu> the actual nexthop in SPF calculation. >> >>First of all as its name says "Link-local Interface Address" >>field contain a link local address and *Not* a global IPv6 >>address, it is clearly mentioned in the RFC >> >>--- >>Link-local Interface Address >> The originating router's link-local interface address on the >> link. >> >>... >> >>Link-LSAs have three purposes: 1) they >> provide the router's link-local address to all other >>routers attached >> to the link and 2) they inform other routers attached to >>the link of >> a list of IPv6 prefixes to associate with the link and 3) >>they allow >> the router to assert a collection of Options bits to associate with >> the Network-LSA that will be originated for the link. >> >>... >> >>A router learns the link-local addresses of all other >> routers attached to its links, and uses these addresses as next hop >> information during packet forwarding. >> >>---- >> >>I think it is clear enough from the above that the global >>address in the Link-LSA is used for announcing those prefix >>to the DR and therefore is irrelevant to nexthop calculation >>which use only link-local address;-) >> >>Last we do not really need Link-LSA for nexthop calculation ( >>as it is mentioned in the RFC ) except for NBMA, since we >>would learn them through Hello reception and the source IPv6 >>address of this packet *is* a link-local address >> >> >>Yasu> It is possible for an implementation to recognize a >>Link-LSA which >>Yasu> has a global-address in 'Link-local Interface Address' >>field as an >>Yasu> invalid Link-LSA. It is just because RFC2740 describes that way >>Yasu> (or the field name indicates that way). >> >>I don't think so, the filed name says clearly what is the >>value of this field otherwise it would have stated that it >>can be an IPv6 address >> >>Yasu> I agree that if OSPFv3 implementation allows, having global >>Yasu> address as nexthop will not be a problem. >> >>Yasu> Route table lookup may ensue further to find link-local address >>Yasu> for it, or NDP(or some other L2-L3 address mapping >>Yasu> mechanism) will work directly on the global address to >>derive its >>Yasu> corresponding L2 address. >> >>The question is Why should I ever need to set the nexthop to >>a global Ipv6 address ? If you tell me that then I would >>agree that RFC need to mention that the nexthop can be set to >>a global IPv6 address. >> >>After all you want to send your packet to your _nexthop_ so >>your neighbor link-local address is the Ipv6 address that is >>always available and least likely to change >> >>Sina >> >> >> >>>sina> If you are referring to FA setting, although if it is >>>necessary to >>>sina> have a global Ipv6 address for FA setting this >> >>address is only >> >>>sina> used to forward a packet to, but this does Not mean that the >>>sina> nexthop is the FA. A router while trying to install a >>>route to the >>>sina> external with FA set needs to just know its nexthop >>>which would be >>>sina> a link-local address ( even if the ASBR setting the FA >>>is directly >>>sina> connected to this router ) >>> >>>Agree, FA will be used to derive actual nexthop, which will be a >>>link-local address in most cases. >>> >>>regards, >>>yasu >>> >> > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Mon Dec 2 11:19:57 2002 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 LAA23379 for ; Mon, 2 Dec 2002 11:19:56 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.0080C2E5@cherry.ease.lsoft.com>; Mon, 2 Dec 2002 11:22:42 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 427423 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 2 Dec 2002 11:22:42 -0500 Received: from 62.241.160.8 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 2 Dec 2002 11:22:42 -0500 Received: from tom3 (userbm24.uk.uudial.com [62.188.144.230]) by nemesis.systems.pipex.net (Postfix) with SMTP id 8CDFE160080F2; Mon, 2 Dec 2002 16:22:37 +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: <004c01c29a1f$044fd680$0301a8c0@tom3> Date: Mon, 2 Dec 2002 16:22:06 -0000 Reply-To: Mailing List Sender: Mailing List From: Tom Petch Subject: draft-ietf-bmwg-ospfconv-term-01.txt Comments: To: bmwg@ietf.org To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit I believe that the terminology used in this document does not reflect current OSPF practice. A Broadcast Link is defined as Networks supporting many (more than two) attached routers, together with the capability to address a single physical message to all of the attached routers (broadcast). In the context of [2] and [3], broadcast links are taken as those on which a designated router is elected. In practice, put together any pair of routers on a LAN (with broadcast capability) and I expect to see a DR elected with its concomitant Network LSA. I appreciate that the wording comes from RFC2328 but that document does later contradict itself with a reference to a DR being elected on any broadcast or NBMA network with at least two routers (ie two does quallify). And for Hello Interval ... The typical hello interval is 10 seconds on broadcast net- works, and 30 seconds for point-to-multipoint and point- to-point networks. RFC2328 suggests 10 second for LANs (broadcast or not) with 30 second for X.25; taking X.25 as the paradign for WAN, this what I see. I cross-post this to the OSPF list since this may provoke different opinions. Tom Petch nwnetworks@dial.pipex.com From owner-ospf@DISCUSS.MICROSOFT.COM Tue Dec 3 00:08:39 2002 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 AAA26725 for ; Tue, 3 Dec 2002 00:08:38 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.0080E391@cherry.ease.lsoft.com>; Tue, 3 Dec 2002 0:01:59 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 429384 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 3 Dec 2002 00:01:59 -0500 Received: from 12.27.183.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 3 Dec 2002 00:01:58 -0500 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <4B0HRHN0>; Tue, 3 Dec 2002 00:01:54 -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: Tue, 3 Dec 2002 00:04:07 -0500 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: OSPFv3 nexthop To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Acee/Sina, I agree to your points. Let me restate my original question. As the Link LSA can have any IPv6 address in the Link-LSA, why is there an explicit restriction that the next hop can only be link-locals? Are there any advantages of having Link-local for nexthops over others? Thanks, Vishwas -----Original Message----- From: Acee Lindem [mailto:acee@REDBACK.COM] Sent: Monday, December 02, 2002 7:31 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: OSPFv3 nexthop Sina Mirtorabi wrote: > Vishwas, > > In short : "nothing prevent an implementation to set the nexthop to any > IPv6 address in Link-LSA" even RFC mention that nexthop is a link-local > address > > In a bit longer ;-) > > Announcing a global IPv6 address for BGP is more a BGP issue than OSPF, > when I redistribute OSPF into BGP and I need to use a third party > nexthop for BGP I can > > 1) change my OSPF nexthop to global IPv6 address in the Link-LSA and > announce this address for BGP nexthop > > 2) Look for a global IPv6 address belonging to my OSPF neighbor and set > BGP nexthop to this value without changing OSPF nexthop ( which is > link-local ). > > This is more an implementation matter .. I still do not see where we > need to change the nexthop to a global IPv6 address for OSPF use ;-) I agree here. OSPFv3 should not install a global nexthop just to make BGP's job easier when determining whether or not a third party nexthop can be advertised. How BGP does this is an implementation matter. > > I would still argue that global IPv6 address in Link-LSA is for > announcing to DR, and link-local address is the only address needed for > nexthop although nothing prevent an implementation to pick up any IPv6 > address in the Link-LSA as nexthop... > > Sina > > > >>Yasu/Sina/Acee, >> >>Thanks for the discussion. >> >>Firstly let me explain the three statements Sina has quoted >>from the draft(which I misconstrued to mean the same Sina did >>earlier). >> >> Link-local Interface Address >> The originating router's link-local interface address on the >> link. >> >>Though this clearly means the link LSA can have only >>link-local address in the Link-local Interface address field, >>global/site local prefixes can always be contained in the >>Address prefix field in the same LSA. There is nothing that >>prevents it(infact because we are using the term "link-local" >>for the constrained field, not using the term for the prefix >>suggests clearly that non link-locals could be used in prefixes. >> >> Link-LSAs have three purposes: 1) they >> provide the router's link-local address to all other >>routers attached >> to the link and 2) they inform other routers attached to >>the link of >> a list of IPv6 prefixes to associate with the link and 3) >>they allow >> the router to assert a collection of Options bits to associate with >> the Network-LSA that will be originated for the link. >> >>This nowhere states that a router cannot have non-link-local >>addresses in "Link LSA". Because the link-local address field >>is compulsary the statement >>1) is correct. The point 2) clearly states that it can inform >>of other addresses too, by not explicitly prefixing the term >>link-local. >> >> A router learns the link-local addresses of all other >> routers attached to its links, and uses these addresses as next hop >> information during packet forwarding. >> >>This statement also does not anyway state that non-link local >>prefixes cannot be used, it only states that link-locals are >>used for nexthop calculation. > > > > >>The requirement that I was talking about in my earlier mail >>wasn't about FA. I was talking about a case where BGP uses >>the IGP nexthop to advertize in its routes, in which case we >>will require a non-local scope address (and as Acee put it >>third-party nexthop) >> >>Thanks, >>Vishwas >> >> >>-----Original Message----- >>From: Sina Mirtorabi [mailto:sina@CISCO.COM] >>Sent: Sunday, December 01, 2002 5:10 PM >>To: OSPF@DISCUSS.MICROSOFT.COM >>Subject: Re: OSPFv3 nexthop >> >> >>Yasu, >> >> >> >>>sina> having global address in Link-LSA is irrelevant to next hop >>>sina> calculation, the fact of carrying global IPv6 address >>>in Link-LSA >>>sina> is just related to announcing all global Ipv6 address of a >>>sina> multi-access link to DR so that it will announce them in its >>>sina> intra-area-prefix LSA >>>sina> >>>sina> Link-local address is the only address to be always >>>available ( as >>>sina> Acee said ) therefore this address can always be used >> >>to reach >> >>>sina> your nexthop and you should not need any other address >>>even a node >>>sina> can have multiple IPv6 address >> >>Yasu> Having a global address in Link-LSA (specifically in >>'Link-local >>Yasu> Interface Address' field) is *not* irrelevant. It will >>be used as >>Yasu> the actual nexthop in SPF calculation. >> >>First of all as its name says "Link-local Interface Address" >>field contain a link local address and *Not* a global IPv6 >>address, it is clearly mentioned in the RFC >> >>--- >>Link-local Interface Address >> The originating router's link-local interface address on the >> link. >> >>... >> >>Link-LSAs have three purposes: 1) they >> provide the router's link-local address to all other >>routers attached >> to the link and 2) they inform other routers attached to >>the link of >> a list of IPv6 prefixes to associate with the link and 3) >>they allow >> the router to assert a collection of Options bits to associate with >> the Network-LSA that will be originated for the link. >> >>... >> >>A router learns the link-local addresses of all other >> routers attached to its links, and uses these addresses as next hop >> information during packet forwarding. >> >>---- >> >>I think it is clear enough from the above that the global >>address in the Link-LSA is used for announcing those prefix >>to the DR and therefore is irrelevant to nexthop calculation >>which use only link-local address;-) >> >>Last we do not really need Link-LSA for nexthop calculation ( >>as it is mentioned in the RFC ) except for NBMA, since we >>would learn them through Hello reception and the source IPv6 >>address of this packet *is* a link-local address >> >> >>Yasu> It is possible for an implementation to recognize a >>Link-LSA which >>Yasu> has a global-address in 'Link-local Interface Address' >>field as an >>Yasu> invalid Link-LSA. It is just because RFC2740 describes that way >>Yasu> (or the field name indicates that way). >> >>I don't think so, the filed name says clearly what is the >>value of this field otherwise it would have stated that it >>can be an IPv6 address >> >>Yasu> I agree that if OSPFv3 implementation allows, having global >>Yasu> address as nexthop will not be a problem. >> >>Yasu> Route table lookup may ensue further to find link-local address >>Yasu> for it, or NDP(or some other L2-L3 address mapping >>Yasu> mechanism) will work directly on the global address to >>derive its >>Yasu> corresponding L2 address. >> >>The question is Why should I ever need to set the nexthop to >>a global Ipv6 address ? If you tell me that then I would >>agree that RFC need to mention that the nexthop can be set to >>a global IPv6 address. >> >>After all you want to send your packet to your _nexthop_ so >>your neighbor link-local address is the Ipv6 address that is >>always available and least likely to change >> >>Sina >> >> >> >>>sina> If you are referring to FA setting, although if it is >>>necessary to >>>sina> have a global Ipv6 address for FA setting this >> >>address is only >> >>>sina> used to forward a packet to, but this does Not mean that the >>>sina> nexthop is the FA. A router while trying to install a >>>route to the >>>sina> external with FA set needs to just know its nexthop >>>which would be >>>sina> a link-local address ( even if the ASBR setting the FA >>>is directly >>>sina> connected to this router ) >>> >>>Agree, FA will be used to derive actual nexthop, which will be a >>>link-local address in most cases. >>> >>>regards, >>>yasu > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Tue Dec 3 07:01:59 2002 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 HAA15686 for ; Tue, 3 Dec 2002 07:01:58 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.0080F31C@cherry.ease.lsoft.com>; Tue, 3 Dec 2002 7:04:40 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 431025 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 3 Dec 2002 07:04:40 -0500 Received: from 171.68.227.73 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 3 Dec 2002 07:04:40 -0500 Received: from smirtoraw2k01 (dhcp-144-254-56-89.cisco.com [144.254.56.89]) by fire.cisco.com (8.11.6+Sun/8.8.8) with ESMTP id gB3C4bO13856 for ; Tue, 3 Dec 2002 04:04:38 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: <018701c29ac4$27aea660$5938fe90@amer.cisco.com> Date: Tue, 3 Dec 2002 04:04:37 -0800 Reply-To: Mailing List Sender: Mailing List From: Sina Mirtorabi Subject: Re: OSPFv3 nexthop To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit Vishwas, > > > Hi Acee/Sina, > > I agree to your points. > > Let me restate my original question. As the Link LSA can have > any IPv6 address in the Link-LSA, why is there an explicit > restriction that the next hop can only be link-locals? As previously stated, nothing prevent an implementation to use any IPv6 address in Link-LSA. As a matter of the fact you can set the nexthop to what ever you want as long as you know how to deliver the packet to your next hop ;-) > Are there any advantages of having Link-local for nexthops over others? - link-local address is always available - least likely to change - If a non-local address is used, you may end up doing an extra-look up - since all OSPF packet use link-local as a source of IPv6 address you have already your layer3/layer2 mapping done and do not need any extra mapping for this new nexthop Sina > > Thanks, > Vishwas > > -----Original Message----- > From: Acee Lindem [mailto:acee@REDBACK.COM] > Sent: Monday, December 02, 2002 7:31 PM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Re: OSPFv3 nexthop > > > Sina Mirtorabi wrote: > > Vishwas, > > > > In short : "nothing prevent an implementation to set the nexthop to > > any IPv6 address in Link-LSA" even RFC mention that nexthop is a > > link-local address > > > > In a bit longer ;-) > > > > Announcing a global IPv6 address for BGP is more a BGP issue than > > OSPF, when I redistribute OSPF into BGP and I need to use a third > > party nexthop for BGP I can > > > > 1) change my OSPF nexthop to global IPv6 address in the > Link-LSA and > > announce this address for BGP nexthop > > > > 2) Look for a global IPv6 address belonging to my OSPF neighbor and > > set BGP nexthop to this value without changing OSPF nexthop > ( which is > > link-local ). > > > > This is more an implementation matter .. I still do not see > where we > > need to change the nexthop to a global IPv6 address for OSPF use ;-) > > I agree here. OSPFv3 should not install a global nexthop just > to make BGP's job easier when determining whether or not a > third party nexthop can be advertised. How BGP does this is > an implementation matter. > > > > > > I would still argue that global IPv6 address in Link-LSA is for > > announcing to DR, and link-local address is the only address needed > > for nexthop although nothing prevent an implementation to > pick up any > > IPv6 address in the Link-LSA as nexthop... > > > > Sina > > > > > > > >>Yasu/Sina/Acee, > >> > >>Thanks for the discussion. > >> > >>Firstly let me explain the three statements Sina has quoted > from the > >>draft(which I misconstrued to mean the same Sina did earlier). > >> > >> Link-local Interface Address > >> The originating router's link-local interface address on the > >> link. > >> > >>Though this clearly means the link LSA can have only link-local > >>address in the Link-local Interface address field, > global/site local > >>prefixes can always be contained in the Address prefix field in the > >>same LSA. There is nothing that prevents it(infact because we are > >>using the term "link-local" for the constrained field, not > using the > >>term for the prefix suggests clearly that non link-locals could be > >>used in prefixes. > >> > >> Link-LSAs have three purposes: 1) they > >> provide the router's link-local address to all other routers > >>attached > >> to the link and 2) they inform other routers attached to > the link > >>of > >> a list of IPv6 prefixes to associate with the link and 3) they > >>allow > >> the router to assert a collection of Options bits to > associate with > >> the Network-LSA that will be originated for the link. > >> > >>This nowhere states that a router cannot have > non-link-local addresses > >>in "Link LSA". Because the link-local address field is > compulsary the > >>statement > >>1) is correct. The point 2) clearly states that it can > inform of other > >>addresses too, by not explicitly prefixing the term link-local. > >> > >> A router learns the link-local addresses of all other > >> routers attached to its links, and uses these addresses > as next hop > >> information during packet forwarding. > >> > >>This statement also does not anyway state that non-link > local prefixes > >>cannot be used, it only states that link-locals are used > for nexthop > >>calculation. > > > > > > > > > >>The requirement that I was talking about in my earlier mail wasn't > >>about FA. I was talking about a case where BGP uses the IGP > nexthop to > >>advertize in its routes, in which case we will require a non-local > >>scope address (and as Acee put it third-party nexthop) > >> > >>Thanks, > >>Vishwas > >> > >> > >>-----Original Message----- > >>From: Sina Mirtorabi [mailto:sina@CISCO.COM] > >>Sent: Sunday, December 01, 2002 5:10 PM > >>To: OSPF@DISCUSS.MICROSOFT.COM > >>Subject: Re: OSPFv3 nexthop > >> > >> > >>Yasu, > >> > >> > >> > >>>sina> having global address in Link-LSA is irrelevant to next hop > >>>sina> calculation, the fact of carrying global IPv6 address > >>>in Link-LSA > >>>sina> is just related to announcing all global Ipv6 address of a > >>>sina> multi-access link to DR so that it will announce them in its > >>>sina> intra-area-prefix LSA > >>>sina> > >>>sina> Link-local address is the only address to be always > >>>available ( as > >>>sina> Acee said ) therefore this address can always be used > >> > >>to reach > >> > >>>sina> your nexthop and you should not need any other address > >>>even a node > >>>sina> can have multiple IPv6 address > >> > >>Yasu> Having a global address in Link-LSA (specifically in > >>'Link-local > >>Yasu> Interface Address' field) is *not* irrelevant. It will > >>be used as > >>Yasu> the actual nexthop in SPF calculation. > >> > >>First of all as its name says "Link-local Interface Address" field > >>contain a link local address and *Not* a global IPv6 address, it is > >>clearly mentioned in the RFC > >> > >>--- > >>Link-local Interface Address > >> The originating router's link-local interface address on the > >> link. > >> > >>... > >> > >>Link-LSAs have three purposes: 1) they > >> provide the router's link-local address to all other routers > >>attached > >> to the link and 2) they inform other routers attached to > the link > >>of > >> a list of IPv6 prefixes to associate with the link and 3) they > >>allow > >> the router to assert a collection of Options bits to > associate with > >> the Network-LSA that will be originated for the link. > >> > >>... > >> > >>A router learns the link-local addresses of all other > >> routers attached to its links, and uses these addresses > as next hop > >> information during packet forwarding. > >> > >>---- > >> > >>I think it is clear enough from the above that the global > address in > >>the Link-LSA is used for announcing those prefix to the DR and > >>therefore is irrelevant to nexthop calculation which use only > >>link-local address;-) > >> > >>Last we do not really need Link-LSA for nexthop calculation > ( as it is > >>mentioned in the RFC ) except for NBMA, since we would learn them > >>through Hello reception and the source IPv6 address of this packet > >>*is* a link-local address > >> > >> > >>Yasu> It is possible for an implementation to recognize a > >>Link-LSA which > >>Yasu> has a global-address in 'Link-local Interface Address' > >>field as an > >>Yasu> invalid Link-LSA. It is just because RFC2740 > describes that way > >>Yasu> (or the field name indicates that way). > >> > >>I don't think so, the filed name says clearly what is the value of > >>this field otherwise it would have stated that it can be an IPv6 > >>address > >> > >>Yasu> I agree that if OSPFv3 implementation allows, having global > >>Yasu> address as nexthop will not be a problem. > >> > >>Yasu> Route table lookup may ensue further to find > link-local address > >>Yasu> for it, or NDP(or some other L2-L3 address mapping > >>Yasu> mechanism) will work directly on the global address to > >>derive its > >>Yasu> corresponding L2 address. > >> > >>The question is Why should I ever need to set the nexthop > to a global > >>Ipv6 address ? If you tell me that then I would agree that > RFC need to > >>mention that the nexthop can be set to a global IPv6 address. > >> > >>After all you want to send your packet to your _nexthop_ so your > >>neighbor link-local address is the Ipv6 address that is always > >>available and least likely to change > >> > >>Sina > >> > >> > >> > >>>sina> If you are referring to FA setting, although if it is > >>>necessary to > >>>sina> have a global Ipv6 address for FA setting this > >> > >>address is only > >> > >>>sina> used to forward a packet to, but this does Not mean that the > >>>sina> nexthop is the FA. A router while trying to install a > >>>route to the > >>>sina> external with FA set needs to just know its nexthop > >>>which would be > >>>sina> a link-local address ( even if the ASBR setting the FA > >>>is directly > >>>sina> connected to this router ) > >>> > >>>Agree, FA will be used to derive actual nexthop, which will be a > >>>link-local address in most cases. > >>> > >>>regards, > >>>yasu > > > > -- > Acee > From owner-ospf@DISCUSS.MICROSOFT.COM Tue Dec 3 07:17:10 2002 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 HAA16002 for ; Tue, 3 Dec 2002 07:17:09 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.0080F393@cherry.ease.lsoft.com>; Tue, 3 Dec 2002 7:19:57 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 431074 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 3 Dec 2002 07:19:57 -0500 Received: from 12.27.183.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 3 Dec 2002 07:19:57 -0500 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <4B0HR2AD>; Tue, 3 Dec 2002 07:19:53 -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: Tue, 3 Dec 2002 07:21:15 -0500 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: OSPFv3 nexthop To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Sina, Thanks for restating the points, restating from the first mail I sent. As nothing prevents us(from the protocol point of view) from using the other IPv6 addresses, the restriction in section 3.8.1.1 In IPv6, the calculation of the next hop's IPv6 address (which will be a link-local address) proceeds along the same lines as the IPv4 next hop calculation (see Section 16.1.1 of [Ref1]). should not be there(which is exactly where I started off from. Saying next hop IPv6 address will be link-local is wrong). Do you agree to the above statement? Thanks, Vishwas -----Original Message----- From: Sina Mirtorabi [mailto:sina@CISCO.COM] Sent: Tuesday, December 03, 2002 5:35 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: OSPFv3 nexthop Vishwas, > > > Hi Acee/Sina, > > I agree to your points. > > Let me restate my original question. As the Link LSA can have > any IPv6 address in the Link-LSA, why is there an explicit > restriction that the next hop can only be link-locals? As previously stated, nothing prevent an implementation to use any IPv6 address in Link-LSA. As a matter of the fact you can set the nexthop to what ever you want as long as you know how to deliver the packet to your next hop ;-) > Are there any advantages of having Link-local for nexthops over others? - link-local address is always available - least likely to change - If a non-local address is used, you may end up doing an extra-look up - since all OSPF packet use link-local as a source of IPv6 address you have already your layer3/layer2 mapping done and do not need any extra mapping for this new nexthop Sina > > Thanks, > Vishwas > > -----Original Message----- > From: Acee Lindem [mailto:acee@REDBACK.COM] > Sent: Monday, December 02, 2002 7:31 PM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Re: OSPFv3 nexthop > > > Sina Mirtorabi wrote: > > Vishwas, > > > > In short : "nothing prevent an implementation to set the nexthop to > > any IPv6 address in Link-LSA" even RFC mention that nexthop is a > > link-local address > > > > In a bit longer ;-) > > > > Announcing a global IPv6 address for BGP is more a BGP issue than > > OSPF, when I redistribute OSPF into BGP and I need to use a third > > party nexthop for BGP I can > > > > 1) change my OSPF nexthop to global IPv6 address in the > Link-LSA and > > announce this address for BGP nexthop > > > > 2) Look for a global IPv6 address belonging to my OSPF neighbor and > > set BGP nexthop to this value without changing OSPF nexthop > ( which is > > link-local ). > > > > This is more an implementation matter .. I still do not see > where we > > need to change the nexthop to a global IPv6 address for OSPF use ;-) > > I agree here. OSPFv3 should not install a global nexthop just > to make BGP's job easier when determining whether or not a > third party nexthop can be advertised. How BGP does this is > an implementation matter. > > > > > > I would still argue that global IPv6 address in Link-LSA is for > > announcing to DR, and link-local address is the only address needed > > for nexthop although nothing prevent an implementation to > pick up any > > IPv6 address in the Link-LSA as nexthop... > > > > Sina > > > > > > > >>Yasu/Sina/Acee, > >> > >>Thanks for the discussion. > >> > >>Firstly let me explain the three statements Sina has quoted > from the > >>draft(which I misconstrued to mean the same Sina did earlier). > >> > >> Link-local Interface Address > >> The originating router's link-local interface address on the > >> link. > >> > >>Though this clearly means the link LSA can have only link-local > >>address in the Link-local Interface address field, > global/site local > >>prefixes can always be contained in the Address prefix field in the > >>same LSA. There is nothing that prevents it(infact because we are > >>using the term "link-local" for the constrained field, not > using the > >>term for the prefix suggests clearly that non link-locals could be > >>used in prefixes. > >> > >> Link-LSAs have three purposes: 1) they > >> provide the router's link-local address to all other routers > >>attached > >> to the link and 2) they inform other routers attached to > the link > >>of > >> a list of IPv6 prefixes to associate with the link and 3) they > >>allow > >> the router to assert a collection of Options bits to > associate with > >> the Network-LSA that will be originated for the link. > >> > >>This nowhere states that a router cannot have > non-link-local addresses > >>in "Link LSA". Because the link-local address field is > compulsary the > >>statement > >>1) is correct. The point 2) clearly states that it can > inform of other > >>addresses too, by not explicitly prefixing the term link-local. > >> > >> A router learns the link-local addresses of all other > >> routers attached to its links, and uses these addresses > as next hop > >> information during packet forwarding. > >> > >>This statement also does not anyway state that non-link > local prefixes > >>cannot be used, it only states that link-locals are used > for nexthop > >>calculation. > > > > > > > > > >>The requirement that I was talking about in my earlier mail wasn't > >>about FA. I was talking about a case where BGP uses the IGP > nexthop to > >>advertize in its routes, in which case we will require a non-local > >>scope address (and as Acee put it third-party nexthop) > >> > >>Thanks, > >>Vishwas > >> > >> > >>-----Original Message----- > >>From: Sina Mirtorabi [mailto:sina@CISCO.COM] > >>Sent: Sunday, December 01, 2002 5:10 PM > >>To: OSPF@DISCUSS.MICROSOFT.COM > >>Subject: Re: OSPFv3 nexthop > >> > >> > >>Yasu, > >> > >> > >> > >>>sina> having global address in Link-LSA is irrelevant to next hop > >>>sina> calculation, the fact of carrying global IPv6 address > >>>in Link-LSA > >>>sina> is just related to announcing all global Ipv6 address of a > >>>sina> multi-access link to DR so that it will announce them in its > >>>sina> intra-area-prefix LSA > >>>sina> > >>>sina> Link-local address is the only address to be always > >>>available ( as > >>>sina> Acee said ) therefore this address can always be used > >> > >>to reach > >> > >>>sina> your nexthop and you should not need any other address > >>>even a node > >>>sina> can have multiple IPv6 address > >> > >>Yasu> Having a global address in Link-LSA (specifically in > >>'Link-local > >>Yasu> Interface Address' field) is *not* irrelevant. It will > >>be used as > >>Yasu> the actual nexthop in SPF calculation. > >> > >>First of all as its name says "Link-local Interface Address" field > >>contain a link local address and *Not* a global IPv6 address, it is > >>clearly mentioned in the RFC > >> > >>--- > >>Link-local Interface Address > >> The originating router's link-local interface address on the > >> link. > >> > >>... > >> > >>Link-LSAs have three purposes: 1) they > >> provide the router's link-local address to all other routers > >>attached > >> to the link and 2) they inform other routers attached to > the link > >>of > >> a list of IPv6 prefixes to associate with the link and 3) they > >>allow > >> the router to assert a collection of Options bits to > associate with > >> the Network-LSA that will be originated for the link. > >> > >>... > >> > >>A router learns the link-local addresses of all other > >> routers attached to its links, and uses these addresses > as next hop > >> information during packet forwarding. > >> > >>---- > >> > >>I think it is clear enough from the above that the global > address in > >>the Link-LSA is used for announcing those prefix to the DR and > >>therefore is irrelevant to nexthop calculation which use only > >>link-local address;-) > >> > >>Last we do not really need Link-LSA for nexthop calculation > ( as it is > >>mentioned in the RFC ) except for NBMA, since we would learn them > >>through Hello reception and the source IPv6 address of this packet > >>*is* a link-local address > >> > >> > >>Yasu> It is possible for an implementation to recognize a > >>Link-LSA which > >>Yasu> has a global-address in 'Link-local Interface Address' > >>field as an > >>Yasu> invalid Link-LSA. It is just because RFC2740 > describes that way > >>Yasu> (or the field name indicates that way). > >> > >>I don't think so, the filed name says clearly what is the value of > >>this field otherwise it would have stated that it can be an IPv6 > >>address > >> > >>Yasu> I agree that if OSPFv3 implementation allows, having global > >>Yasu> address as nexthop will not be a problem. > >> > >>Yasu> Route table lookup may ensue further to find > link-local address > >>Yasu> for it, or NDP(or some other L2-L3 address mapping > >>Yasu> mechanism) will work directly on the global address to > >>derive its > >>Yasu> corresponding L2 address. > >> > >>The question is Why should I ever need to set the nexthop > to a global > >>Ipv6 address ? If you tell me that then I would agree that > RFC need to > >>mention that the nexthop can be set to a global IPv6 address. > >> > >>After all you want to send your packet to your _nexthop_ so your > >>neighbor link-local address is the Ipv6 address that is always > >>available and least likely to change > >> > >>Sina > >> > >> > >> > >>>sina> If you are referring to FA setting, although if it is > >>>necessary to > >>>sina> have a global Ipv6 address for FA setting this > >> > >>address is only > >> > >>>sina> used to forward a packet to, but this does Not mean that the > >>>sina> nexthop is the FA. A router while trying to install a > >>>route to the > >>>sina> external with FA set needs to just know its nexthop > >>>which would be > >>>sina> a link-local address ( even if the ASBR setting the FA > >>>is directly > >>>sina> connected to this router ) > >>> > >>>Agree, FA will be used to derive actual nexthop, which will be a > >>>link-local address in most cases. > >>> > >>>regards, > >>>yasu > Acee > From owner-ospf@DISCUSS.MICROSOFT.COM Tue Dec 3 09:40:42 2002 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 JAA22550 for ; Tue, 3 Dec 2002 09:40:42 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.0080F642@cherry.ease.lsoft.com>; Tue, 3 Dec 2002 9:43:23 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 431419 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 3 Dec 2002 09:43:22 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 3 Dec 2002 09:43:22 -0500 Received: from redback.com (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id 9FAE539B5AA for ; Tue, 3 Dec 2002 06:43:20 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; 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 Message-ID: <3DECC38F.9020401@redback.com> Date: Tue, 3 Dec 2002 09:45:35 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: OSPFv3 nexthop To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Manral, Vishwas wrote: > Hi Sina, > > Thanks for restating the points, restating from the first mail I sent. > > As nothing prevents us(from the protocol point of view) from using the other > IPv6 addresses, the restriction in section 3.8.1.1 > > In IPv6, the calculation of the next hop's IPv6 address (which will > be a link-local address) proceeds along the same lines as the IPv4 > next hop calculation (see Section 16.1.1 of [Ref1]). > > should not be there(which is exactly where I started off from. Saying next > hop IPv6 address will be link-local is wrong). > > Do you agree to the above statement? Hi Vishwas, I'm not sure I'd agree that the RFC is wrong. The link-local address is certainly the most straightforward (for the reasons Sina mentions) and there is certainly some value in having all OSPFv3 implementations calculate their routes the same way. Also, this text has withstood all the review cycles. You could install a global next-hop address and still be compatible. Thanks, Acee > > Thanks, > Vishwas > > -----Original Message----- > From: Sina Mirtorabi [mailto:sina@CISCO.COM] > Sent: Tuesday, December 03, 2002 5:35 PM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Re: OSPFv3 nexthop > > > Vishwas, > > >> >>Hi Acee/Sina, >> >>I agree to your points. >> >>Let me restate my original question. As the Link LSA can have >>any IPv6 address in the Link-LSA, why is there an explicit >>restriction that the next hop can only be link-locals? > > > As previously stated, nothing prevent an implementation to use any IPv6 > address in Link-LSA. As a matter of the fact you can set the nexthop to > what ever you want as long as you know how to deliver the packet to your > next hop ;-) > > >>Are there any advantages of having Link-local for nexthops over > > others? > > - link-local address is always available > - least likely to change > - If a non-local address is used, you may end up doing an extra-look up > - since all OSPF packet use link-local as a source of IPv6 address you > have already your layer3/layer2 mapping done and do not need any extra > mapping for this new nexthop > > Sina > > > >>Thanks, >>Vishwas >> >>-----Original Message----- >>From: Acee Lindem [mailto:acee@REDBACK.COM] >>Sent: Monday, December 02, 2002 7:31 PM >>To: OSPF@DISCUSS.MICROSOFT.COM >>Subject: Re: OSPFv3 nexthop >> >> >>Sina Mirtorabi wrote: >> >>>Vishwas, >>> >>>In short : "nothing prevent an implementation to set the nexthop to >>>any IPv6 address in Link-LSA" even RFC mention that nexthop is a >>>link-local address >>> >>>In a bit longer ;-) >>> >>>Announcing a global IPv6 address for BGP is more a BGP issue than >>>OSPF, when I redistribute OSPF into BGP and I need to use a third >>>party nexthop for BGP I can >>> >>>1) change my OSPF nexthop to global IPv6 address in the >> >>Link-LSA and >> >>>announce this address for BGP nexthop >>> >>>2) Look for a global IPv6 address belonging to my OSPF neighbor and >>>set BGP nexthop to this value without changing OSPF nexthop >> >>( which is >> >>>link-local ). >>> >>>This is more an implementation matter .. I still do not see >> >>where we >> >>>need to change the nexthop to a global IPv6 address for OSPF use ;-) >> >>I agree here. OSPFv3 should not install a global nexthop just >>to make BGP's job easier when determining whether or not a >>third party nexthop can be advertised. How BGP does this is >>an implementation matter. >> >> >> >>>I would still argue that global IPv6 address in Link-LSA is for >>>announcing to DR, and link-local address is the only address needed >>>for nexthop although nothing prevent an implementation to >> >>pick up any >> >>>IPv6 address in the Link-LSA as nexthop... >>> >>>Sina >>> >>> >>> >>> >>>>Yasu/Sina/Acee, >>>> >>>>Thanks for the discussion. >>>> >>>>Firstly let me explain the three statements Sina has quoted >>> >>from the >> >>>>draft(which I misconstrued to mean the same Sina did earlier). >>>> >>>> Link-local Interface Address >>>> The originating router's link-local interface address on the >>>> link. >>>> >>>>Though this clearly means the link LSA can have only link-local >>>>address in the Link-local Interface address field, >>> >>global/site local >> >>>>prefixes can always be contained in the Address prefix field in the >>>>same LSA. There is nothing that prevents it(infact because we are >>>>using the term "link-local" for the constrained field, not >>> >>using the >> >>>>term for the prefix suggests clearly that non link-locals could be >>>>used in prefixes. >>>> >>>> Link-LSAs have three purposes: 1) they >>>> provide the router's link-local address to all other routers >>>>attached >>>> to the link and 2) they inform other routers attached to >>> >>the link >> >>>>of >>>> a list of IPv6 prefixes to associate with the link and 3) they >>>>allow >>>> the router to assert a collection of Options bits to >>> >>associate with >> >>>> the Network-LSA that will be originated for the link. >>>> >>>>This nowhere states that a router cannot have >>> >>non-link-local addresses >> >>>>in "Link LSA". Because the link-local address field is >>> >>compulsary the >> >>>>statement >>>>1) is correct. The point 2) clearly states that it can >>> >>inform of other >> >>>>addresses too, by not explicitly prefixing the term link-local. >>>> >>>> A router learns the link-local addresses of all other >>>> routers attached to its links, and uses these addresses >>> >>as next hop >> >>>> information during packet forwarding. >>>> >>>>This statement also does not anyway state that non-link >>> >>local prefixes >> >>>>cannot be used, it only states that link-locals are used >>> >>for nexthop >> >>>>calculation. >>> >>> >>> >>> >>>>The requirement that I was talking about in my earlier mail wasn't >>>>about FA. I was talking about a case where BGP uses the IGP >>> >>nexthop to >> >>>>advertize in its routes, in which case we will require a non-local >>>>scope address (and as Acee put it third-party nexthop) >>>> >>>>Thanks, >>>>Vishwas >>>> >>>> >>>>-----Original Message----- >>>>From: Sina Mirtorabi [mailto:sina@CISCO.COM] >>>>Sent: Sunday, December 01, 2002 5:10 PM >>>>To: OSPF@DISCUSS.MICROSOFT.COM >>>>Subject: Re: OSPFv3 nexthop >>>> >>>> >>>>Yasu, >>>> >>>> >>>> >>>> >>>>>sina> having global address in Link-LSA is irrelevant to next hop >>>>>sina> calculation, the fact of carrying global IPv6 address >>>>>in Link-LSA >>>>>sina> is just related to announcing all global Ipv6 address of a >>>>>sina> multi-access link to DR so that it will announce them in its >>>>>sina> intra-area-prefix LSA >>>>>sina> >>>>>sina> Link-local address is the only address to be always >>>>>available ( as >>>>>sina> Acee said ) therefore this address can always be used >>>> >>>>to reach >>>> >>>> >>>>>sina> your nexthop and you should not need any other address >>>>>even a node >>>>>sina> can have multiple IPv6 address >>>> >>>>Yasu> Having a global address in Link-LSA (specifically in >>>>'Link-local >>>>Yasu> Interface Address' field) is *not* irrelevant. It will >>>>be used as >>>>Yasu> the actual nexthop in SPF calculation. >>>> >>>>First of all as its name says "Link-local Interface Address" field >>>>contain a link local address and *Not* a global IPv6 address, it is >>>>clearly mentioned in the RFC >>>> >>>>--- >>>>Link-local Interface Address >>>> The originating router's link-local interface address on the >>>> link. >>>> >>>>... >>>> >>>>Link-LSAs have three purposes: 1) they >>>> provide the router's link-local address to all other routers >>>>attached >>>> to the link and 2) they inform other routers attached to >>> >>the link >> >>>>of >>>> a list of IPv6 prefixes to associate with the link and 3) they >>>>allow >>>> the router to assert a collection of Options bits to >>> >>associate with >> >>>> the Network-LSA that will be originated for the link. >>>> >>>>... >>>> >>>>A router learns the link-local addresses of all other >>>> routers attached to its links, and uses these addresses >>> >>as next hop >> >>>> information during packet forwarding. >>>> >>>>---- >>>> >>>>I think it is clear enough from the above that the global >>> >>address in >> >>>>the Link-LSA is used for announcing those prefix to the DR and >>>>therefore is irrelevant to nexthop calculation which use only >>>>link-local address;-) >>>> >>>>Last we do not really need Link-LSA for nexthop calculation >>> >>( as it is >> >>>>mentioned in the RFC ) except for NBMA, since we would learn them >>>>through Hello reception and the source IPv6 address of this packet >>>>*is* a link-local address >>>> >>>> >>>>Yasu> It is possible for an implementation to recognize a >>>>Link-LSA which >>>>Yasu> has a global-address in 'Link-local Interface Address' >>>>field as an >>>>Yasu> invalid Link-LSA. It is just because RFC2740 >>> >>describes that way >> >>>>Yasu> (or the field name indicates that way). >>>> >>>>I don't think so, the filed name says clearly what is the value of >>>>this field otherwise it would have stated that it can be an IPv6 >>>>address >>>> >>>>Yasu> I agree that if OSPFv3 implementation allows, having global >>>>Yasu> address as nexthop will not be a problem. >>>> >>>>Yasu> Route table lookup may ensue further to find >>> >>link-local address >> >>>>Yasu> for it, or NDP(or some other L2-L3 address mapping >>>>Yasu> mechanism) will work directly on the global address to >>>>derive its >>>>Yasu> corresponding L2 address. >>>> >>>>The question is Why should I ever need to set the nexthop >>> >>to a global >> >>>>Ipv6 address ? If you tell me that then I would agree that >>> >>RFC need to >> >>>>mention that the nexthop can be set to a global IPv6 address. >>>> >>>>After all you want to send your packet to your _nexthop_ so your >>>>neighbor link-local address is the Ipv6 address that is always >>>>available and least likely to change >>>> >>>>Sina >>>> >>>> >>>> >>>> >>>>>sina> If you are referring to FA setting, although if it is >>>>>necessary to >>>>>sina> have a global Ipv6 address for FA setting this >>>> >>>>address is only >>>> >>>> >>>>>sina> used to forward a packet to, but this does Not mean that the >>>>>sina> nexthop is the FA. A router while trying to install a >>>>>route to the >>>>>sina> external with FA set needs to just know its nexthop >>>>>which would be >>>>>sina> a link-local address ( even if the ASBR setting the FA >>>>>is directly >>>>>sina> connected to this router ) >>>>> >>>>>Agree, FA will be used to derive actual nexthop, which will be a >>>>>link-local address in most cases. >>>>> >>>>>regards, >>>>>yasu >>>> >>Acee >> > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Tue Dec 3 09:44:28 2002 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 JAA22877 for ; Tue, 3 Dec 2002 09:44:28 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.0080F681@cherry.ease.lsoft.com>; Tue, 3 Dec 2002 9:47:16 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 431448 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 3 Dec 2002 09:47:16 -0500 Received: from 171.68.227.73 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 3 Dec 2002 09:47:16 -0500 Received: from smirtoraw2k01 (dhcp-144-254-56-89.cisco.com [144.254.56.89]) by fire.cisco.com (8.11.6+Sun/8.8.8) with ESMTP id gB3ElBO23839 for ; Tue, 3 Dec 2002 06:47:11 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: <01c501c29ada$dccff740$5938fe90@amer.cisco.com> Date: Tue, 3 Dec 2002 06:47:10 -0800 Reply-To: Mailing List Sender: Mailing List From: Sina Mirtorabi Subject: Re: OSPFv3 nexthop To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit Vishwas, > -----Original Message----- > From: Mailing List [mailto:OSPF@DISCUSS.MICROSOFT.COM] On > Behalf Of Manral, Vishwas > Sent: Tuesday, December 03, 2002 4:21 AM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Re: OSPFv3 nexthop > > > Hi Sina, > > Thanks for restating the points, restating from the first mail I sent. > > As nothing prevents us(from the protocol point of view) from > using the other IPv6 addresses, the restriction in section 3.8.1.1 > > In IPv6, the calculation of the next hop's IPv6 address (which will > be a link-local address) proceeds along the same lines as the IPv4 > next hop calculation (see Section 16.1.1 of [Ref1]). > > should not be there(which is exactly where I started off > from. Saying next hop IPv6 address will be link-local is wrong). > > Do you agree to the above statement? Not really ;-) the question that you have not yet replied to, is that why should we ever need to change the nexthop to a non-link-local address for OSPF use ? The fact that an implementation can put any address as a nexthop does not mean that RFC need to be changed to not mention explicitly that nexthop is a link-local If you put the nexthop to a non-link-local address are you RFC non-compliant ? I don't think so since nexthop setting is internal to your router and does not cause any interoperability problem So let's leave the RFC wording as it is unless there is a case scenario in which link-local address will Not work for OSPF use ;-) Sina > > Thanks, > Vishwas > > -----Original Message----- > From: Sina Mirtorabi [mailto:sina@CISCO.COM] > Sent: Tuesday, December 03, 2002 5:35 PM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Re: OSPFv3 nexthop > > > Vishwas, > > > > > > > Hi Acee/Sina, > > > > I agree to your points. > > > > Let me restate my original question. As the Link LSA can > have any IPv6 > > address in the Link-LSA, why is there an explicit > restriction that the > > next hop can only be link-locals? > > As previously stated, nothing prevent an implementation to > use any IPv6 address in Link-LSA. As a matter of the fact you > can set the nexthop to what ever you want as long as you know > how to deliver the packet to your next hop ;-) > > > Are there any advantages of having Link-local for nexthops over > others? > > - link-local address is always available > - least likely to change > - If a non-local address is used, you may end up doing an > extra-look up > - since all OSPF packet use link-local as a source of IPv6 > address you have already your layer3/layer2 mapping done and > do not need any extra mapping for this new nexthop > > Sina > > > > > > Thanks, > > Vishwas > > > > -----Original Message----- > > From: Acee Lindem [mailto:acee@REDBACK.COM] > > Sent: Monday, December 02, 2002 7:31 PM > > To: OSPF@DISCUSS.MICROSOFT.COM > > Subject: Re: OSPFv3 nexthop > > > > > > Sina Mirtorabi wrote: > > > Vishwas, > > > > > > In short : "nothing prevent an implementation to set the > nexthop to > > > any IPv6 address in Link-LSA" even RFC mention that nexthop is a > > > link-local address > > > > > > In a bit longer ;-) > > > > > > Announcing a global IPv6 address for BGP is more a BGP issue than > > > OSPF, when I redistribute OSPF into BGP and I need to use a third > > > party nexthop for BGP I can > > > > > > 1) change my OSPF nexthop to global IPv6 address in the > > Link-LSA and > > > announce this address for BGP nexthop > > > > > > 2) Look for a global IPv6 address belonging to my OSPF > neighbor and > > > set BGP nexthop to this value without changing OSPF nexthop > > ( which is > > > link-local ). > > > > > > This is more an implementation matter .. I still do not see > > where we > > > need to change the nexthop to a global IPv6 address for > OSPF use ;-) > > > > I agree here. OSPFv3 should not install a global nexthop > just to make > > BGP's job easier when determining whether or not a third > party nexthop > > can be advertised. How BGP does this is an implementation matter. > > > > > > > > > > I would still argue that global IPv6 address in Link-LSA is for > > > announcing to DR, and link-local address is the only > address needed > > > for nexthop although nothing prevent an implementation to > > pick up any > > > IPv6 address in the Link-LSA as nexthop... > > > > > > Sina > > > > > > > > > > > >>Yasu/Sina/Acee, > > >> > > >>Thanks for the discussion. > > >> > > >>Firstly let me explain the three statements Sina has quoted > > from the > > >>draft(which I misconstrued to mean the same Sina did earlier). > > >> > > >> Link-local Interface Address > > >> The originating router's link-local interface address on the > > >> link. > > >> > > >>Though this clearly means the link LSA can have only link-local > > >>address in the Link-local Interface address field, > > global/site local > > >>prefixes can always be contained in the Address prefix > field in the > > >>same LSA. There is nothing that prevents it(infact because we are > > >>using the term "link-local" for the constrained field, not > > using the > > >>term for the prefix suggests clearly that non link-locals > could be > > >>used in prefixes. > > >> > > >> Link-LSAs have three purposes: 1) they > > >> provide the router's link-local address to all other routers > > >>attached > > >> to the link and 2) they inform other routers attached to > > the link > > >>of > > >> a list of IPv6 prefixes to associate with the link and 3) they > > >>allow > > >> the router to assert a collection of Options bits to > > associate with > > >> the Network-LSA that will be originated for the link. > > >> > > >>This nowhere states that a router cannot have > > non-link-local addresses > > >>in "Link LSA". Because the link-local address field is > > compulsary the > > >>statement > > >>1) is correct. The point 2) clearly states that it can > > inform of other > > >>addresses too, by not explicitly prefixing the term link-local. > > >> > > >> A router learns the link-local addresses of all other > > >> routers attached to its links, and uses these addresses > > as next hop > > >> information during packet forwarding. > > >> > > >>This statement also does not anyway state that non-link > > local prefixes > > >>cannot be used, it only states that link-locals are used > > for nexthop > > >>calculation. > > > > > > > > > > > > > > >>The requirement that I was talking about in my earlier > mail wasn't > > >>about FA. I was talking about a case where BGP uses the IGP > > nexthop to > > >>advertize in its routes, in which case we will require a > non-local > > >>scope address (and as Acee put it third-party nexthop) > > >> > > >>Thanks, > > >>Vishwas > > >> > > >> > > >>-----Original Message----- > > >>From: Sina Mirtorabi [mailto:sina@CISCO.COM] > > >>Sent: Sunday, December 01, 2002 5:10 PM > > >>To: OSPF@DISCUSS.MICROSOFT.COM > > >>Subject: Re: OSPFv3 nexthop > > >> > > >> > > >>Yasu, > > >> > > >> > > >> > > >>>sina> having global address in Link-LSA is irrelevant to > next hop > > >>>sina> calculation, the fact of carrying global IPv6 address > > >>>in Link-LSA > > >>>sina> is just related to announcing all global Ipv6 address of a > > >>>sina> multi-access link to DR so that it will announce > them in its > > >>>sina> intra-area-prefix LSA > > >>>sina> > > >>>sina> Link-local address is the only address to be always > > >>>available ( as > > >>>sina> Acee said ) therefore this address can always be used > > >> > > >>to reach > > >> > > >>>sina> your nexthop and you should not need any other address > > >>>even a node > > >>>sina> can have multiple IPv6 address > > >> > > >>Yasu> Having a global address in Link-LSA (specifically in > > >>'Link-local > > >>Yasu> Interface Address' field) is *not* irrelevant. It will > > >>be used as > > >>Yasu> the actual nexthop in SPF calculation. > > >> > > >>First of all as its name says "Link-local Interface > Address" field > > >>contain a link local address and *Not* a global IPv6 > address, it is > > >>clearly mentioned in the RFC > > >> > > >>--- > > >>Link-local Interface Address > > >> The originating router's link-local interface address on the > > >> link. > > >> > > >>... > > >> > > >>Link-LSAs have three purposes: 1) they > > >> provide the router's link-local address to all other routers > > >>attached > > >> to the link and 2) they inform other routers attached to > > the link > > >>of > > >> a list of IPv6 prefixes to associate with the link and 3) they > > >>allow > > >> the router to assert a collection of Options bits to > > associate with > > >> the Network-LSA that will be originated for the link. > > >> > > >>... > > >> > > >>A router learns the link-local addresses of all other > > >> routers attached to its links, and uses these addresses > > as next hop > > >> information during packet forwarding. > > >> > > >>---- > > >> > > >>I think it is clear enough from the above that the global > > address in > > >>the Link-LSA is used for announcing those prefix to the DR and > > >>therefore is irrelevant to nexthop calculation which use only > > >>link-local address;-) > > >> > > >>Last we do not really need Link-LSA for nexthop calculation > > ( as it is > > >>mentioned in the RFC ) except for NBMA, since we would learn them > > >>through Hello reception and the source IPv6 address of this packet > > >>*is* a link-local address > > >> > > >> > > >>Yasu> It is possible for an implementation to recognize a > > >>Link-LSA which > > >>Yasu> has a global-address in 'Link-local Interface Address' > > >>field as an > > >>Yasu> invalid Link-LSA. It is just because RFC2740 > > describes that way > > >>Yasu> (or the field name indicates that way). > > >> > > >>I don't think so, the filed name says clearly what is the > value of > > >>this field otherwise it would have stated that it can be an IPv6 > > >>address > > >> > > >>Yasu> I agree that if OSPFv3 implementation allows, having global > > >>Yasu> address as nexthop will not be a problem. > > >> > > >>Yasu> Route table lookup may ensue further to find > > link-local address > > >>Yasu> for it, or NDP(or some other L2-L3 address mapping > > >>Yasu> mechanism) will work directly on the global address to > > >>derive its > > >>Yasu> corresponding L2 address. > > >> > > >>The question is Why should I ever need to set the nexthop > > to a global > > >>Ipv6 address ? If you tell me that then I would agree that > > RFC need to > > >>mention that the nexthop can be set to a global IPv6 address. > > >> > > >>After all you want to send your packet to your _nexthop_ so your > > >>neighbor link-local address is the Ipv6 address that is always > > >>available and least likely to change > > >> > > >>Sina > > >> > > >> > > >> > > >>>sina> If you are referring to FA setting, although if it is > > >>>necessary to > > >>>sina> have a global Ipv6 address for FA setting this > > >> > > >>address is only > > >> > > >>>sina> used to forward a packet to, but this does Not > mean that the > > >>>sina> nexthop is the FA. A router while trying to install a > > >>>route to the > > >>>sina> external with FA set needs to just know its nexthop > > >>>which would be > > >>>sina> a link-local address ( even if the ASBR setting the FA > > >>>is directly > > >>>sina> connected to this router ) > > >>> > > >>>Agree, FA will be used to derive actual nexthop, which will be a > > >>>link-local address in most cases. > > >>> > > >>>regards, > > >>>yasu > > Acee > > > From owner-ospf@DISCUSS.MICROSOFT.COM Wed Dec 4 12:04:56 2002 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 MAA22110 for ; Wed, 4 Dec 2002 12:04:55 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00812A2A@cherry.ease.lsoft.com>; Wed, 4 Dec 2002 12:07:42 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 436208 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 4 Dec 2002 12:07:41 -0500 Received: from 12.27.183.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 4 Dec 2002 12:07:41 -0500 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <4B0HRK7T>; Wed, 4 Dec 2002 12:07:41 -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: Wed, 4 Dec 2002 12:09:50 -0500 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: [bmwg] draft-ietf-bmwg-ospfconv-term-01.txt Comments: To: Tom Petch , bmwg@ietf.org To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Tom, Thanks for the comment and sorry for the delayed reply. Well regarding the first comment I guess we have tried not to repeat definitions in the OSPF RFC itself. The definitions we have given are more in context of the methodology draft which I guess has been stated. However if there are any contradictions we will remove them. Regarding the second comment, those values were put in more in response to a comment that typical values used in production networks may be put in, into the draft. Looking at that in perspective I feel that as such values change, we could do without such things in the terminology draft itself. Thanks, Vishwas -----Original Message----- From: Tom Petch [mailto:nwnetworks@dial.pipex.com] Sent: Monday, December 02, 2002 9:52 PM To: bmwg@ietf.org Cc: OSPF Subject: [bmwg] draft-ietf-bmwg-ospfconv-term-01.txt I believe that the terminology used in this document does not reflect current OSPF practice. A Broadcast Link is defined as Networks supporting many (more than two) attached routers, together with the capability to address a single physical message to all of the attached routers (broadcast). In the context of [2] and [3], broadcast links are taken as those on which a designated router is elected. In practice, put together any pair of routers on a LAN (with broadcast capability) and I expect to see a DR elected with its concomitant Network LSA. I appreciate that the wording comes from RFC2328 but that document does later contradict itself with a reference to a DR being elected on any broadcast or NBMA network with at least two routers (ie two does quallify). And for Hello Interval ... The typical hello interval is 10 seconds on broadcast net- works, and 30 seconds for point-to-multipoint and point- to-point networks. RFC2328 suggests 10 second for LANs (broadcast or not) with 30 second for X.25; taking X.25 as the paradign for WAN, this what I see. I cross-post this to the OSPF list since this may provoke different opinions. Tom Petch nwnetworks@dial.pipex.com From owner-ospf@DISCUSS.MICROSOFT.COM Wed Dec 4 13:23:15 2002 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 NAA26748 for ; Wed, 4 Dec 2002 13:23:13 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00812CD4@cherry.ease.lsoft.com>; Wed, 4 Dec 2002 13:26:01 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 436616 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 4 Dec 2002 13:26:01 -0500 Received: from 147.28.0.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 4 Dec 2002 13:26:00 -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 18JeDZ-000FGM-00; Wed, 04 Dec 2002 10:25:53 -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: <121158569851.20021204102519@psg.com> Date: Wed, 4 Dec 2002 10:25:19 -0800 Reply-To: Mailing List Sender: Mailing List From: Alex Zinin Subject: Fwd: IETF Sub-IP area: request for input Comments: To: routing-discussion@ietf.org Comments: cc: isis-wg@ietf.org To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit FYI below. (Sorry for cross-posting.) Please post follow-ups to ietf@ietf.org. -- Alex This is a forwarded message From: The IESG To: Cc: Date: Wednesday, December 04, 2002, 8:08:49 AM Subject: IETF Sub-IP area: request for input ===8<==============Original message text=============== IETF SUB-IP area The IESG announced in November of 2000 that a new SUB-IP temporary pseudo-area would be formed as a part of an effort to develop a "systematic approach to dealing with what we used to describe as "sub-IP" technologies." At the time the IESG said: "Over the years the boundary between 'wires' and IP protocols has become harder to define and the interaction has become more intertwined. For example, what appear as 'wires' or 'circuits' in a virtual network may in fact be routed datagrams in an underlying IP network. The topology of dynamic underlying networks such as ATM and soon switched optical networks can interact with IP-level traffic engineering and routing. Additionally, with IETF technologies such as MPLS we are defining a whole new class of 'wires'." (http://www.ietf.org/IESG/STATEMENTS/new-area.txt) After the December 2000 IETF meeting and taking into account the discussion at that meeting the IESG formed a "temporary" SUB-IP Area. IN the announcement of this action the IESG said: "It is temporary because the IESG believes that this concentrated sub-IP effort will likely be of short duration, on the order of a year or two. We feel that much of the work will be done by then, and the working groups closed. Any working groups that have not finished when the IESG determines that the area should be closed will be moved into existing the IETF areas where they seem to have the best fit." and "The IESG expects to review the development process and charters, however; if we conclude that this expectation is incorrect, we will need to make this area more formal. At that point, the nominating committee will be asked to supply dedicated area directors." (http://www.ietf.org/IESG/STATEMENTS/sub_area.txt) Although the SUB-IP working groups have made considerable progress (with 7 RFCs published, another 12 IDs approved for publication, 9 IDs under IESG consideration and an additional 11 IDs having been passed to the ADs for their evaluation) their work is not yet done (with 53 working group IDs currently in progress). It does appear that some of the working groups could finish the work in their charters over the next 6 months but it could be a lot longer for others. Because the end is in sight for some of the working groups and since the IESG had generally assumed that the area would be a temporary one and the second anniversary of the creation of the SUB-IP area is next spring, analysis was started in the IESG to figure out which areas would be the best ones for the SUB-IP working groups to move to so that they could continue their work. As part of that analysis a SUB-IP area session was held during the IETF meeting in Atlanta where this topic was discussed. There was a spirited discussion during the session on the best path forward. The opinions ranged from following the distribution of working groups, to doing so with some specific changes to keeping the working groups in a separate SUB-IP area. A sense of the room was taken at the end of the discussion and that sense was very strongly that the SUB-IP Area should become a "long-term" (the description that was used during the consensus call) one and that the nomcom be asked to nominate a person (or persons) to become director(s) of the SUB-IP area. To help provide more information as input for the IESG discussion we would like to continue the discussion started in Atlanta on the mailing list. It is our intention to keep the discussion on the future of the SUB-IP area open, but short-lived, because it would be a very good idea to let the nomcom know ASAP what the future holds as they need to know what expertise is needed in the ADs for the existing areas and if they need to search for additional people. The IESG aim is to be able to let the nomcom know what the future of the SUB-IP work is by the end of the day of Thursday Dec 12th. That date was chosen because it is the date of the next IESG teleconference yet it provides some time for a public discussion. The options seem to be: 1/ move WGs (back) to permanent areas: migrate the SUB-IP working groups to other IETF areas sometime soon, likely before next summer and close the SUB-IP area. Also, reconstitute the SUB-IP (and/or other) directorates to ensure the continued coordination between the remaining WGs. 2/ establish a long-term area: decide that the SUB-IP area will be a long-term one, clearly define its charter, and ask the nomcom to select one or two people to be Area Directors 3/ status quo: continue the SUB-IP Area as a temporary, ad-hoc effort, much as it has been, with the IESG selecting two sitting ADs to continue the effort that Bert & Scott have been doing. But maybe give more responsibility to the working group's technical advisors, normally the AD from the area where the working group might otherwise live. Data points for the discussion: DP1. It does look like a number of the SUB-IP working groups will be finishing up their main work in the next year and be ready to be closed until it is time to revise the RFCs based on experience or to advance them on the standards track. The groups that should be finishing up include ipo, gsmp and tewg. That would leave mpls, ppvpn and ccamp. DP2. WGs in SUB-IP or the work pursued in them came from existing well-established areas, i.e., tewg came from OPS, gsmp, mpls (with ccamp and ppvpn as its derivatives) came from RTG. DP3. There's still a need for technical oversight from permanent areas, so some WGs have a technical advisor--normally the AD from the area where the working group might otherwise live (e.g. CCAMP, and PPVPN with a RTG AD as the TA). DP4. SUB-IP directorate was very useful when the area was just created. It is currently passive and WGs continue operating just fine. DP5. The sense of the SUB-IP session in Atlanta was that the SUB-IP Area was working and there is no compelling reason to break it up. There is a need to clarify the charters of some of the working groups so that the different groups understand what the division of tasks are but it is hard to identify what problem would be solved by breaking up the area. DP6. Extensions to specific IETF technologies should be done in the working groups responsible for those technologies based on requirements provided by other working groups. For example, extensions to OSPF should be done by the OSPF working group based on input from other working groups or individuals rather than being done someplace else. Discussions about the options: 1/ Move WGs (back) to permanent areas and close the area For: Each WG within SUB-IP definitely has a strong feature that maps it to a given permanent area [1]. The property that logically holds them together in SUB-IP now is the need for coordination wrt the technologies that are normally considered below the IP layer. While this was indeed necessary right after SUB-IP creation, DP4 suggests that the goal has been achieved and the focus is shifting back to coordination with permanent areas (e.g., DP3, as well as the fact that RTG WGs are already dealing with SUB-IP related extensions). DP1 suggests that there will be about three active WGs within a year; at least two of them can be argued to belong in RTG area (where they originally came from, see DP2), so it wouldn't make a lot of sense to have two separate areas overlapping so considerably. PPVPN does not map strongly to any area, however it doesn't map strongly to SUB-IP either (MPLS is just one possible encapsulation method) Against: DP5 suggests that the feeling in the room was against closing the area, though there was also some support for the idea that moving MPLS and CCAMP to RTG would be a fine idea if the area were to be closed. The feeling was that the area has been working and that there is no strong argument that there is a need to change things at this time. 2/ Establish a long-term area For: DP5 suggests that the community believes this is a good idea. See also the "Against" for option 1. In addition the opinion was expressed that having a specific area with specifically assigned management, knowledgeable in the field, would be an advantage. In addition, new SUP-IP work may develop in the future and it would be good to have a home for it. Against: See "For" arguments for option 1 above. Also, there was an assumption when the area was formed that it would be temporary and the size of the IESG is near max effective size. It is also expected that if the nomcom needs to find an AD(s) for SUB-IP, the set of required skills would be extremely similar to those needed for the RTG area, which again brings up the question of whether it makes sense to have two areas with so similar expertise scopes. 3/ Status quo For: DP5 suggests that the way the area operates is fine and does not need fixing at this time. As DP1 predicts, there may not be many active SUB-IP working groups within a year and it may be best to wait until a few of the working groups finish their work and close before deciding on the long term direction for this work. The IESG would decide which ADs would be asked to manage the area in March. Against: A decision has to be made sooner or later, delaying the decision will not make it any easier to make. The IESG would like to hear from the community on this topic - please direct your comments to the ietf@ietf.org list. The IESG will discuss the matter in its next telechat on December 12. -------------------------------------------------- [1] possible WG to area mappings: - IPO has the IP-over-foo property, which is usually addressed in INT, - GSMP came from RTG - MPLS (aside from the fact that it came from RTG) deals with a technology that is arguably another IP forwarding paradigm and relies heavily on regular routing functionality and/or protocols. - CCAMP works on a generalized version of MPLS, which could map it to RTG as well - TEWG came from O&M - PPVPN: suggestions have been made of INT, because its tunneling which is closest to INT, RTG because some of the suggested discovery and VPN routing mechanisms, and TSV, because its related to PWE3 (in TSV because of congestion control worries) ===8<===========End of original message text=========== From owner-ospf@DISCUSS.MICROSOFT.COM Wed Dec 4 16:38:46 2002 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 QAA05108 for ; Wed, 4 Dec 2002 16:38:46 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.008134C7@cherry.ease.lsoft.com>; Wed, 4 Dec 2002 16:41:35 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 437153 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 4 Dec 2002 16:41:35 -0500 Received: from 204.192.44.242 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 4 Dec 2002 16:41:35 -0500 Received: (qmail 32416 invoked from network); 4 Dec 2002 21:41:34 -0000 Received: from bigbird.xebeo.com (192.168.0.21) by lxmail.xebeo.com with SMTP; 4 Dec 2002 21:41:34 -0000 Received: from bigbird.xebeo.com (localhost.localdomain [127.0.0.1]) by bigbird.xebeo.com (8.9.3/8.9.3) with ESMTP id QAA17513 for ; Wed, 4 Dec 2002 16:41:34 -0500 X-Mailer: exmh version 2.1.1 10/15/1999 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <200212042141.QAA17513@bigbird.xebeo.com> Date: Wed, 4 Dec 2002 16:41:34 -0500 Reply-To: Mailing List Sender: Mailing List From: Rohit Dube Subject: Consensus on flooding optimizations To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Folks, Here is my read on the WG discussion. The authors of draft-ash-manral-ospf-congestion-control-00.txt feel that flooding optimizations should be part of the charter. Several others in the WG including the WG co-chairs believe that this should not be included in the charter at this time. A show of hands at the Atlanta meeting confirmed the latter. Thus the consensus is to exclude this item from the current charter proposal. Regards, --rohit/acee. From owner-ospf@DISCUSS.MICROSOFT.COM Thu Dec 5 00:19:43 2002 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 AAA20555 for ; Thu, 5 Dec 2002 00:19:43 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00814571@cherry.ease.lsoft.com>; Thu, 5 Dec 2002 0:13:36 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 438417 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 5 Dec 2002 00:13:35 -0500 Received: from 203.199.83.27 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 5 Dec 2002 00:13:34 -0500 Received: (qmail 28547 invoked by uid 510); 5 Dec 2002 05:11:35 -0000 Received: from unknown (203.197.138.201) by rediffmail.com via HTTP; 05 dec 2002 05:11:35 -0000 MIME-Version: 1.0 Content-type: text/plain; format=flowed Content-Disposition: inline Message-ID: <20021205051135.28546.qmail@webmail17.rediffmail.com> Date: Thu, 5 Dec 2002 05:11:35 -0000 Reply-To: Mailing List Sender: Mailing List From: Krishna Rao Subject: Type-7 to Type-5 translation To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi, I have few doubts with regards to below translation: Reference : NSSA draft 11 Section : 4.2 Step 2 ------- If the Type-7 LSA is not contained in any explicitly configured Type-7 address range and the calculating router has the highest router ID amongst NSSA translators which have originated a functionally equivalent Type-5 LSA (i.e. same destination, cost and non-zero forwarding address) and which are reachable over area 0 and the NSSA, then a Type-5 LSA should be generated if there currently is no Type-5 LSA originating from this router corresponding to the Type-7 LSA's network or there is an existing Type-5 LSA and either it corresponds to a local OSPF external source whose path type and metric is less preferred (see Section 3.5 step (6), parts (b) and (d)) or it doesn't and the Type-5 LSA's path type or cost(s) have changed (See Section 3.5 step (5)) or the forwarding address no longer maps to a translatable Type-7 LSA. Q1) Case when there is existing Type-5 Lsa: "corresponds to a local OSPF external source " what does this exactly mean ? Does it mean, the Type-5 external route learned by NSSA ABR (Translator), which is not result of Type-7 to Type-5 translation, but it is describing the same network, which will be described by resulting translated Type-5. Q2)"or it doesn't and the Type-5 LSA's path type or cost(s) have changed". Does this imply comparison between path type and cost of: 1)Type-5 (result of Type-7 translation) 2)Type-5 (result of Type-7 translation, but now path/cost has changed) For e.g Previously translated Type-7 Lsa has Type-2 external path. New Type-7 Lsa (new instance of previous) has Type-1 external path. So resulting Type-5 needs to reflect the path change. Thanks in advance, krishna From owner-ospf@DISCUSS.MICROSOFT.COM Thu Dec 5 00:19:43 2002 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 AAA20558 for ; Thu, 5 Dec 2002 00:19:43 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.008144E8@cherry.ease.lsoft.com>; Thu, 5 Dec 2002 0:20:46 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 438440 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 5 Dec 2002 00:20:44 -0500 Received: from 203.199.83.27 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 5 Dec 2002 00:20:43 -0500 Received: (qmail 5401 invoked by uid 510); 5 Dec 2002 05:18:44 -0000 Received: from unknown (203.197.138.201) by rediffmail.com via HTTP; 05 dec 2002 05:18:44 -0000 MIME-Version: 1.0 Content-type: text/plain; format=flowed Content-Disposition: inline Message-ID: <20021205051844.5400.qmail@webmail17.rediffmail.com> Date: Thu, 5 Dec 2002 05:18:44 -0000 Reply-To: Mailing List Sender: Mailing List From: Krishna Rao Subject: Nssa Translation(Fwd Address) To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi, With regards to following: NSSA draft :11 Section :4.2 Step :2 ----------------- "or the forwarding address no longer maps to a translatable Type-7 LSA." Q1)Does it refer to, Type-5 Lsa which is result of Type-7 translation(network N , fwd address x.x.x.x), but now fwd address of Type-7 has changed(netwrok N, fwd address y.y.y.y). So new Type-5 needs to be generated. thanks, krishna From owner-ospf@DISCUSS.MICROSOFT.COM Thu Dec 5 03:22:59 2002 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 DAA03974 for ; Thu, 5 Dec 2002 03:22:59 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.00814A61@cherry.ease.lsoft.com>; Thu, 5 Dec 2002 3:25:47 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 439128 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 5 Dec 2002 03:25:47 -0500 Received: from 203.199.83.38 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 5 Dec 2002 03:25:47 -0500 Received: (qmail 14727 invoked by uid 510); 5 Dec 2002 08:24:21 -0000 Received: from unknown (203.197.138.201) by rediffmail.com via HTTP; 05 dec 2002 08:24:21 -0000 MIME-Version: 1.0 Content-type: text/plain; format=flowed Content-Disposition: inline Message-ID: <20021205082421.14726.qmail@webmail28.rediffmail.com> Date: Thu, 5 Dec 2002 08:24:21 -0000 Reply-To: Mailing List Sender: Mailing List From: Krishna Rao Subject: Nssa Terminology To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi, I had some doubts, as to what exactly NSSA draft 11 means, when it uses terms like: 1) Locally sourced Type-7 LSAs. 2) Type-5 LSA originating from a local OSPF external source. 3) Locally sourced Type-5 LSAs. thanks, krishna From owner-ospf@DISCUSS.MICROSOFT.COM Thu Dec 5 07:51:23 2002 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 HAA09604 for ; Thu, 5 Dec 2002 07:51:22 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.008159E0@cherry.ease.lsoft.com>; Thu, 5 Dec 2002 7:54:10 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 441556 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 5 Dec 2002 07:54:10 -0500 Received: from 171.68.227.73 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 5 Dec 2002 07:54:10 -0500 Received: from smirtoraw2k01 (dhcp-144-254-56-89.cisco.com [144.254.56.89]) by fire.cisco.com (8.11.6+Sun/8.8.8) with ESMTP id gB5Cs8O23488 for ; Thu, 5 Dec 2002 04:54:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: <03f001c29c5d$66b450e0$5938fe90@amer.cisco.com> Date: Thu, 5 Dec 2002 04:54:07 -0800 Reply-To: Mailing List Sender: Mailing List From: Sina Mirtorabi Subject: Re: Type-7 to Type-5 translation To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <20021205051135.28546.qmail@webmail17.rediffmail.com> Precedence: list Content-Transfer-Encoding: 7bit Krishna , > > Hi, > I have few doubts with regards to below translation: > > Reference : NSSA draft 11 > Section : 4.2 > Step 2 > ------- > If the Type-7 LSA is not contained in any explicitly > configured Type-7 address range and the calculating router > has the highest router ID amongst NSSA translators which have > originated a functionally equivalent Type-5 LSA (i.e. same > destination, cost and non-zero forwarding address) and which > are reachable over area 0 and the NSSA, then a Type-5 LSA > should be generated if there currently is no Type-5 LSA > originating from this router corresponding to the Type-7 > LSA's network or there is an existing Type-5 LSA and either > it corresponds to a local OSPF external source whose path > type and metric is less preferred (see Section 3.5 step (6), parts > (b) and (d)) or it doesn't and the Type-5 LSA's path type or > cost(s) have changed (See Section 3.5 step (5)) or the > forwarding address no longer maps to a translatable Type-7 LSA. Ok let me rephrase the above a bit in a simplify form, the translator will translate a type 7 LSA if either of the below is satisfied - there is not currently a type 5 generated by this router( as a result of translation) - there is a type 5 generated by this router ( but not as a result of translation, that is locally sourced ) which has less proffered metric (type) compared to the type 7 - there is a type 5 generated by this router ( as a result of translation ) but metric or FA changed therefore a new type 5 is needed to be generated > > Q1) Case when there is existing Type-5 Lsa: > "corresponds to a local OSPF external source " > what does this exactly mean ? An ABR attached to a NSSA area while redistributing, it can originate type 5 directly into attached non-NSSA-area this is called local sourced type 5 LSA ( not as a result of translation ) > Does it mean, the Type-5 external route learned by NSSA ABR > (Translator), which is not result of Type-7 to Type-5 > translation, > but it is describing the same network, which will be described by > resulting translated Type-5. No, local OSPF external source means that the ABR is directly generating type 5 into non-NSSA-area ( see above ) > > Q2)"or it doesn't and the Type-5 LSA's path type or > cost(s) have changed". > > Does this imply comparison between path type and cost of: > 1)Type-5 (result of Type-7 translation) > 2)Type-5 (result of Type-7 translation, but now path/cost has > changed) > For e.g > Previously translated Type-7 Lsa has Type-2 external path. > New Type-7 Lsa (new instance of previous) has Type-1 > external path. > So resulting Type-5 needs to reflect the path change. Correct Sina > > Thanks in advance, > krishna > From owner-ospf@DISCUSS.MICROSOFT.COM Thu Dec 5 07:52:04 2002 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 HAA09626 for ; Thu, 5 Dec 2002 07:52:04 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.00815902@cherry.ease.lsoft.com>; Thu, 5 Dec 2002 7:54:53 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 441574 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 5 Dec 2002 07:54:53 -0500 Received: from 171.68.227.73 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 5 Dec 2002 07:54:53 -0500 Received: from smirtoraw2k01 (dhcp-144-254-56-89.cisco.com [144.254.56.89]) by fire.cisco.com (8.11.6+Sun/8.8.8) with ESMTP id gB5CsqO24081 for ; Thu, 5 Dec 2002 04:54:52 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: <03f101c29c5d$807a8580$5938fe90@amer.cisco.com> Date: Thu, 5 Dec 2002 04:54:51 -0800 Reply-To: Mailing List Sender: Mailing List From: Sina Mirtorabi Subject: Re: Nssa Translation(Fwd Address) To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <20021205051844.5400.qmail@webmail17.rediffmail.com> Precedence: list Content-Transfer-Encoding: 7bit krishna > -----Original Message----- > From: Mailing List [mailto:OSPF@DISCUSS.MICROSOFT.COM] On > Behalf Of Krishna Rao > Sent: Wednesday, December 04, 2002 9:19 PM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Nssa Translation(Fwd Address) > > > Hi, > With regards to following: > NSSA draft :11 > Section :4.2 > Step :2 > ----------------- > "or the forwarding address no longer maps to a > translatable Type-7 LSA." > > Q1)Does it refer to, Type-5 Lsa which is result of Type-7 > translation(network N , fwd address x.x.x.x), but now > fwd address of Type-7 has changed(netwrok N, fwd address > y.y.y.y). > So new Type-5 needs to be generated. Yes Sina > > thanks, > krishna > From owner-ospf@DISCUSS.MICROSOFT.COM Thu Dec 5 08:07:05 2002 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 IAA09962 for ; Thu, 5 Dec 2002 08:07:05 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.008158D8@cherry.ease.lsoft.com>; Thu, 5 Dec 2002 8:09:54 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 441675 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 5 Dec 2002 08:09:54 -0500 Received: from 171.68.227.73 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 5 Dec 2002 08:09:54 -0500 Received: from smirtoraw2k01 (dhcp-144-254-56-89.cisco.com [144.254.56.89]) by fire.cisco.com (8.11.6+Sun/8.8.8) with ESMTP id gB5D9qO09064 for ; Thu, 5 Dec 2002 05:09:52 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: <03f201c29c5f$995bc670$5938fe90@amer.cisco.com> Date: Thu, 5 Dec 2002 05:09:51 -0800 Reply-To: Mailing List Sender: Mailing List From: Sina Mirtorabi Subject: Re: Nssa Terminology To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <20021205082421.14726.qmail@webmail28.rediffmail.com> Precedence: list Content-Transfer-Encoding: 7bit Krishna, > -----Original Message----- > From: Mailing List [mailto:OSPF@DISCUSS.MICROSOFT.COM] On > Behalf Of Krishna Rao > Sent: Thursday, December 05, 2002 12:24 AM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Nssa Terminology > > > Hi, > I had some doubts, as to what exactly NSSA draft 11 means, > when it uses terms like: > 1) Locally sourced Type-7 LSAs. The router is attached to NSSA area and generate a type 7 LSA as a result of redistributing external information into OSPF > 2) Type-5 LSA originating from a local OSPF external source. This means that the router is learning external information locally from another source ( say BGP ) and originate type 5 LSA as a result of redistribution > 3) Locally sourced Type-5 LSAs. The router is originating the type 5 LSA, either as a result of 2) or as a result of translation of type 7 to 5 Sina > > thanks, > krishna > From owner-ospf@DISCUSS.MICROSOFT.COM Fri Dec 6 01:55:53 2002 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 BAA17109 for ; Fri, 6 Dec 2002 01:55:52 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00817AE6@cherry.ease.lsoft.com>; Fri, 6 Dec 2002 1:58:35 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 444696 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 6 Dec 2002 01:58:35 -0500 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 6 Dec 2002 01:58:35 -0500 Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id gB66wYS97233; Thu, 5 Dec 2002 22:58:34 -0800 (PST) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) with ESMTP id gB66wYN99841; Thu, 5 Dec 2002 22:58:34 -0800 (PST) (envelope-from kireeti@juniper.net) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: <20021205224441.X99669-100000@kummer.juniper.net> Date: Thu, 5 Dec 2002 22:58:34 -0800 Reply-To: Mailing List Sender: Mailing List From: Kireeti Kompella Subject: Re: I-D ACTION:draft-ietf-ccamp-ospf-gmpls-extensions-09.txt Comments: To: ccamp@ops.ietf.org To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <200212041235.HAA07652@ietf.org> Precedence: list Hi All, On Wed, 4 Dec 2002 Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. > > Title : OSPF Extensions in Support of Generalized MPLS > Author(s) : K. Kompella, Y. Rekhter > Filename : draft-ietf-ccamp-ospf-gmpls-extensions-09.txt > Pages : 12 > Date : 2002-12-3 > > This document specifies encoding of extensions to the OSPF routing > protocol in support of Generalized Multi-Protocol Label Switching. The CCAMP WG Last Call for draft-ietf-ccamp-ospf-gmpls-extensions-08.txt and for draft-ietf-ccamp-gmpls-routing-05.txt ended Aug 28, 2002; the authors only got one comment on the former (a typo). The new version announced above fixes the typo, makes some minor formatting changes, and spruces up the Security Considerations (essentially copied from the OSPF TE doc). The latter document is unchanged. The OSPF WG was notified on Sept 30, 2002 that the above documents finished CCAMP WG Last Call; no comments were received in the two week window soliciting comments. These documents will now be forwarded to the IESG as standards track documents requesting an IETF Last Call. Kireeti. From owner-ospf@DISCUSS.MICROSOFT.COM Sat Dec 7 21:32:38 2002 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 VAA12442 for ; Sat, 7 Dec 2002 21:32:37 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.00820282@cherry.ease.lsoft.com>; Sat, 7 Dec 2002 21:35:27 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 455099 for OSPF@DISCUSS.MICROSOFT.COM; Sat, 7 Dec 2002 21:35:27 -0500 Received: from 216.136.129.22 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Sat, 7 Dec 2002 21:25:27 -0500 Received: from [141.153.145.101] by web9406.mail.yahoo.com via HTTP; Sat, 07 Dec 2002 18:25:26 PST MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-576711027-1039314326=:79263" Message-ID: <20021208022526.86132.qmail@web9406.mail.yahoo.com> Date: Sat, 7 Dec 2002 18:25:26 -0800 Reply-To: Mailing List Sender: Mailing List From: Anju Patel To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list --0-576711027-1039314326=:79263 Content-Type: text/plain; charset=us-ascii hi I have couple of questions about ospf 1) what are the methods to reduce size of the LSP database in OSPF or IS-IS? 2) For OSPF routers that are connected to a multiple access medium- what is the method used to exchange the LSP-DB? 3) How does one connect an OSPF area that does not have a link to Area0? 4) what are the primary differences between RIP and OSPF? Thanks. --------------------------------- Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now --0-576711027-1039314326=:79263 Content-Type: text/html; charset=us-ascii

hi

I have couple of questions about ospf

1) what are the methods to reduce size of the LSP database in OSPF or IS-IS?

2) For OSPF routers that are connected to a multiple access medium- what is the method used to exchange the LSP-DB?

3) How does one connect an OSPF area that does not have a link to Area0?

4) what are the primary differences between RIP and OSPF?

Thanks.


Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now --0-576711027-1039314326=:79263-- From owner-ospf@DISCUSS.MICROSOFT.COM Sun Dec 8 05:26:51 2002 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 FAA28841 for ; Sun, 8 Dec 2002 05:26:51 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00820AC6@cherry.ease.lsoft.com>; 8 Dec 2002 5:29:40 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 455581 for OSPF@DISCUSS.MICROSOFT.COM; Sun, 8 Dec 2002 05:29:39 -0500 Received: from 12.27.183.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Sun, 8 Dec 2002 05:29:39 -0500 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <4B0HRQ5Z>; Sun, 8 Dec 2002 05:29:38 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C29EA4.F64B4B70" Message-ID: Date: Sun, 8 Dec 2002 05:31:26 -0500 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C29EA4.F64B4B70 Content-Type: text/plain; charset="iso-8859-1" Hi Anju, 1) Well, if you want to reduce the size of the database in an Area, you could configure the area as either Stub or NSSA. You can check the draft http://www.ietf.org/internet-drafts/draft-ietf-ospf-nssa-update-11.txt and RFC2328 for details. Besides in OSPF there is a technique called DBOverflow, that allows handling of unanticipated database overflows - RFC1765. 2) You may like to see the flooding procedure Section 13, and section 10.3 neighbor state machine. The basic idea is that a DR/BDR is elected for each broadcast link, and non-DR routers form adjacencies with only DR/BDR. The DR-other sends LSUpdate packets to the address ALLDRRouters and DR/BDr send to ALLSPF routers. Thanks, Vishwas -----Original Message----- From: Anju Patel [mailto:anjalipatel1@YAHOO.COM] Sent: Sunday, December 08, 2002 7:55 AM To: OSPF@DISCUSS.MICROSOFT.COM Subject: hi I have couple of questions about ospf 1) what are the methods to reduce size of the LSP database in OSPF or IS-IS? 2) For OSPF routers that are connected to a multiple access medium- what is the method used to exchange the LSP-DB? 3) How does one connect an OSPF area that does not have a link to Area0? 4) what are the primary differences between RIP and OSPF? Thanks. ------_=_NextPart_001_01C29EA4.F64B4B70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi=20 Anju,
 
1)=20 Well, if you want to reduce the size of the database in an Area, you = could=20 configure the area as either Stub or NSSA.
You  can check the draft http://www.ietf.org/internet-drafts/draft-ietf-ospf-nssa-update-= 11.txt and=20 RFC2328 for details.
 
Besides in OSPF there is a technique called = DBOverflow,=20 that allows handling of unanticipated database overflows -=20 RFC1765.
 
2) You=20 may like to see the flooding procedure Section 13, and section 10.3 = neighbor=20 state machine. The basic idea is that a DR/BDR is elected for each = broadcast=20 link, and non-DR routers form adjacencies with only DR/BDR. The = DR-other sends=20 LSUpdate packets to the address ALLDRRouters and DR/BDr send to ALLSPF=20 routers.
 
Thanks,
Vishwas
 
-----Original=20 Message-----
From: Anju Patel=20 [mailto:anjalipatel1@YAHOO.COM]
Sent: Sunday, December 08, = 2002 7:55=20 AM
To: OSPF@DISCUSS.MICROSOFT.COM
Subject:=20

hi

I have couple of questions about ospf

1) what are the methods to reduce size of the LSP database in OSPF = or=20 IS-IS?

2) For OSPF routers that are connected to a multiple access = medium- what is=20 the method used to exchange the LSP-DB?

3) How does one connect an OSPF area that does not have a link to=20 Area0?

4) what are the primary differences between RIP and OSPF?

Thanks.

------_=_NextPart_001_01C29EA4.F64B4B70-- From owner-ospf*ospf-archive**LISTS*-IETF*-ORG@DISCUSS.MICROSOFT.COM Tue Dec 10 11:56:35 2002 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 LAA13599 for ; Tue, 10 Dec 2002 11:56:35 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00826EE7@cherry.ease.lsoft.com>; Tue, 10 Dec 2002 11:59:22 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 465226 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 10 Dec 2002 11:59:22 -0500 Received: from 147.28.0.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 10 Dec 2002 11:59:21 -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 18Lnj4-000A3d-00; Tue, 10 Dec 2002 08:59:18 -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: <56159511465.20021210085848@psg.com> Date: Tue, 10 Dec 2002 08:58:48 -0800 Reply-To: Mailing List Sender: Mailing List From: Alex Zinin Subject: Fwd: Reminder: Deadline for input on sub-ip discussion Comments: To: routing-discussion@ietf.org Comments: cc: isis-wg@ietf.org To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit From the ietf-discussion list. -- Alex This is a forwarded message From: Harald Tveit Alvestrand To: ietf@ietf.org Cc: Date: Monday, December 09, 2002, 1:21:59 PM Subject: Reminder: Deadline for input on sub-ip discussion ===8<==============Original message text=============== All, On Wed Dec 4th, we asked for input to help us decide on the future of the SUB-IP Area. See our posting at http://www.ietf.org/mail-archive/ietf/Current/msg18370.html We had a large majority of people at the SUBIP Area meeting in Atlanta expressing that they want the area to be long(er) lived. This will be part of our input. But we need/want to hear from the IETF community. So please express your opionion (and the reasoning behind it) asap on ietf@ietf.org, but certainly before Thursday Dec 12th 10am US Eastern time. As expressed in the above posting (with data points and discussion included), the 3 choices for the SUB-IP Area seem to be: 1/ move WGs (back) to permanent areas: migrate the SUB-IP working groups to other IETF areas sometime soon, likely before next summer and close the SUB-IP area. Also, reconstitute the SUB-IP (and/or other) directorates to ensure the continued coordination between the remaining WGs. 2/ establish a long-term area: decide that the SUB-IP area will be a long-term one, clearly define its charter, and ask the nomcom to select one or two people to be Area Directors 3/ status quo: continue the SUB-IP Area as a temporary, ad-hoc effort, much as it has been, with the IESG selecting two sitting ADs to continue the effort that Bert & Scott have been doing. But maybe give more responsibility to the working group's technical advisors, normally the AD from the area where the working group might otherwise live. The opinions expressed so far seem to show clearly that the community is divided on the issue, with perhaps some preference for the status quo (alternative 3). If you have a strong preference for one (or two) of these, and have not yet said so, please indicate your opinion (and your reasons) by mail to ietf@ietf.org before Thursday. Thank you! Harald Alvestrand, for the IESG (please repost this message where appropriate) ===8<===========End of original message text=========== From owner-ospf@DISCUSS.MICROSOFT.COM Tue Dec 10 18:56:45 2002 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 SAA25309 for ; Tue, 10 Dec 2002 18:56:45 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00828572@cherry.ease.lsoft.com>; Tue, 10 Dec 2002 18:59:38 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 466564 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 10 Dec 2002 18:59:37 -0500 Received: from 65.205.166.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 10 Dec 2002 18:59:37 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Topic: OSPF Link state request list management question Thread-Index: AcKgqDGELevvuDkPR1eF1LAhaRPvyQ== Message-ID: <9BBB98592D94084DB7118F889CFD3EC57FC657@atlntex01.movaz.com> Date: Tue, 10 Dec 2002 18:59:37 -0500 Reply-To: Mailing List Sender: Mailing List From: "Dovolsky, Dan" Subject: OSPF Link state request list management question To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA25309 BSD. I will be appreciated to anyone who can help me with following question: Suppose we have some triangle network topology (routers A,B and C) where each router has two adjacencies. Router A has rebooted. After restart, it attempts to reestablish adjacency with routers B and C. After exchange DB descriptors, Router B decided, that it has to request some missing LSA from router A and send request to it. Immediately after that, router B received this missing LSA from router C (adjacency between A and C comes first). When the requested LSA received from router A, adjacency between B and A is restarted. This behavior proved to be real on Cisco router, and it actually defined by spec: OSPF RFC2328, section 13. The Flooding Procedure states: "(6) Else, if there is an instance of the LSA on the sending neighbor's Link state request list, an error has occurred in the Database Exchange process. In this case, restart the Database Exchange process by generating the neighbor event BadLSReq for the sending neighbor and stop processing the Link State Update packet." However, in section 13.3. Next step in the flooding procedure: "Also included in this part of the flooding procedure is the maintenance of the neighbors' Link state request lists. .... (b) Else, if the adjacency is not yet full (neighbor state is Exchange or Loading), examine the Link state request list associated with this adjacency. If there is an instance of the new LSA on the list, it indicates that the neighboring router has an instance of the LSA already. Compare the new LSA to the neighbor's copy: o If the new LSA is less recent, then examine the next neighbor. o If the two copies are the same instance, then delete the LSA from the Link state request list, and examine the next neighbor.[20] o Else, the new LSA is more recent. Delete the LSA from the Link state request list. (c) If the new LSA was received from this neighbor, examine the next neighbor." My question is why OSPF needs that section 13 (6) part and require unnecessary adjacency restarting ? Following to this section 6 text (sections 7 and 8) define this case processing very well: "(7) Else, if the received LSA is the same instance as the database copy (i.e., neither one is more recent) the following two steps should be performed: (a) If the LSA is listed in the Link state retransmission list for the receiving adjacency, the router itself is expecting an acknowledgment for this LSA. The router should treat the received LSA as an acknowledgment by removing the LSA from the Link state retransmission list. This is termed an "implied acknowledgment". Its occurrence should be noted for later use by the acknowledgment process (Section 13.5). (b) Possibly acknowledge the receipt of the LSA by sending a Link State Acknowledgment packet back out the receiving interface. This is explained below in Section 13.5. (8) Else, the database copy is more recent. If the database copy has LS age equal to MaxAge and LS sequence number equal to MaxSequenceNumber, simply discard the received LSA without acknowledging it. (In this case, the LSA's LS sequence number is wrapping, and the MaxSequenceNumber LSA must be completely flushed before any new LSA instance can be introduced). Otherwise, as long as the database copy has not been sent in a Link State Update within the last MinLSArrival seconds, send the database copy back to the sending neighbor, encapsulated within a Link State Update Packet. The Link State Update Packet should be sent directly to the neighbor..." Regards, Dan Dovolsky. Office: 703-847-2438 ddovolsky@movaz.com From owner-ospf@DISCUSS.MICROSOFT.COM Wed Dec 11 05:01:33 2002 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 FAA00020 for ; Wed, 11 Dec 2002 05:01:32 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.0082CE34@cherry.ease.lsoft.com>; Wed, 11 Dec 2002 5:04:25 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 469769 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 11 Dec 2002 05:04:25 -0500 Received: from 12.27.183.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 11 Dec 2002 05:04:25 -0500 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <4B0HRWWQ>; Wed, 11 Dec 2002 05:04:25 -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: Wed, 11 Dec 2002 05:06:31 -0500 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: OSPF Link state request list management question To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Dan, I am a bit confused about the scenario you have given, however let me try to explain the behavior as given in the RFC(I think I got ur scenario right), I am not sure about the Cisco implementation though. 1. Router B has an LSA x in the Link-State Request list on neighbors A and C. 2. Now B gets the LSA from C. When this happens it removes the LSA from the request list of A(I think you miss this step). 3. Now we get the same LSA from A, the link state request list of A however does not contain this LSA, as it has been removed in step 2. 4. Hence we do not meet condition in step 6(of the RFC), and go to step 7, and perform the steps needed when the same instance is got. Regarding why in step 6 we restart DB exchange, I think it is because the step does not occur in a valid condition, so if the condition is met something is wrong with the DB exchange and hence the DB exchange is restarted for precuation sake. Regarding the an implementation which goes wrong in the above scenario, I think it is probably a timing issue, where the LSA has been updated in the LSDB but not removed from the request list, and the processing of the new LSA is begun in the timeframe. Please let me know if I have addressed ur concerns. Thanks, Vishwas -----Original Message----- From: Dovolsky, Dan [mailto:ddovolsky@MOVAZ.COM] Sent: Wednesday, December 11, 2002 5:30 AM To: OSPF@DISCUSS.MICROSOFT.COM Subject: OSPF Link state request list management question BSD. I will be appreciated to anyone who can help me with following question: Suppose we have some triangle network topology (routers A,B and C) where each router has two adjacencies. Router A has rebooted. After restart, it attempts to reestablish adjacency with routers B and C. After exchange DB descriptors, Router B decided, that it has to request some missing LSA from router A and send request to it. Immediately after that, router B received this missing LSA from router C (adjacency between A and C comes first). When the requested LSA received from router A, adjacency between B and A is restarted. This behavior proved to be real on Cisco router, and it actually defined by spec: OSPF RFC2328, section 13. The Flooding Procedure states: "(6) Else, if there is an instance of the LSA on the sending neighbor's Link state request list, an error has occurred in the Database Exchange process. In this case, restart the Database Exchange process by generating the neighbor event BadLSReq for the sending neighbor and stop processing the Link State Update packet." However, in section 13.3. Next step in the flooding procedure: "Also included in this part of the flooding procedure is the maintenance of the neighbors' Link state request lists. .... (b) Else, if the adjacency is not yet full (neighbor state is Exchange or Loading), examine the Link state request list associated with this adjacency. If there is an instance of the new LSA on the list, it indicates that the neighboring router has an instance of the LSA already. Compare the new LSA to the neighbor's copy: o If the new LSA is less recent, then examine the next neighbor. o If the two copies are the same instance, then delete the LSA from the Link state request list, and examine the next neighbor.[20] o Else, the new LSA is more recent. Delete the LSA from the Link state request list. (c) If the new LSA was received from this neighbor, examine the next neighbor." My question is why OSPF needs that section 13 (6) part and require unnecessary adjacency restarting ? Following to this section 6 text (sections 7 and 8) define this case processing very well: "(7) Else, if the received LSA is the same instance as the database copy (i.e., neither one is more recent) the following two steps should be performed: (a) If the LSA is listed in the Link state retransmission list for the receiving adjacency, the router itself is expecting an acknowledgment for this LSA. The router should treat the received LSA as an acknowledgment by removing the LSA from the Link state retransmission list. This is termed an "implied acknowledgment". Its occurrence should be noted for later use by the acknowledgment process (Section 13.5). (b) Possibly acknowledge the receipt of the LSA by sending a Link State Acknowledgment packet back out the receiving interface. This is explained below in Section 13.5. (8) Else, the database copy is more recent. If the database copy has LS age equal to MaxAge and LS sequence number equal to MaxSequenceNumber, simply discard the received LSA without acknowledging it. (In this case, the LSA's LS sequence number is wrapping, and the MaxSequenceNumber LSA must be completely flushed before any new LSA instance can be introduced). Otherwise, as long as the database copy has not been sent in a Link State Update within the last MinLSArrival seconds, send the database copy back to the sending neighbor, encapsulated within a Link State Update Packet. The Link State Update Packet should be sent directly to the neighbor..." Regards, Dan Dovolsky. Office: 703-847-2438 ddovolsky@movaz.com From owner-ospf@DISCUSS.MICROSOFT.COM Wed Dec 11 05:35:33 2002 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 FAA00976 for ; Wed, 11 Dec 2002 05:35:32 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.0082CDE4@cherry.ease.lsoft.com>; Wed, 11 Dec 2002 5:38:27 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 469876 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 11 Dec 2002 05:38:27 -0500 Received: from 216.136.129.110 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 11 Dec 2002 05:38:27 -0500 Received: from [141.153.159.85] by web9404.mail.yahoo.com via HTTP; Wed, 11 Dec 2002 02:38:26 PST MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1439459654-1039603106=:26064" Message-ID: <20021211103826.26290.qmail@web9404.mail.yahoo.com> Date: Wed, 11 Dec 2002 02:38:26 -0800 Reply-To: Mailing List Sender: Mailing List From: Anju Patel To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list --0-1439459654-1039603106=:26064 Content-Type: text/plain; charset=us-ascii Hi all, I will appreciate a lot if someone can answers. 1)What are the methods to reduce size of the LSP database in OSPF or IS-IS? 2)What are the methods to reduce the I-BGP load in a network?why is this necessary?when is it necessary? 3)What conditions must a route meet among other comepeting routes to the same destination, to be transferred from the BGP-RIB to the FIB? Thanks a lot. Anju. --------------------------------- Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now --0-1439459654-1039603106=:26064 Content-Type: text/html; charset=us-ascii

Hi all,

I will appreciate a lot if someone can answers.

1)What are the methods to reduce size of the LSP database in OSPF or IS-IS?

2)What are the methods to reduce the I-BGP load in a network?why is this necessary?when is it necessary?

3)What conditions must a route meet among other comepeting routes to the same destination, to be transferred from the BGP-RIB to the FIB?

Thanks a lot.

Anju.


Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now --0-1439459654-1039603106=:26064-- From owner-ospf@DISCUSS.MICROSOFT.COM Wed Dec 11 05:39:52 2002 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 FAA01039 for ; Wed, 11 Dec 2002 05:39:51 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.0082CD53@cherry.ease.lsoft.com>; Wed, 11 Dec 2002 5:42:47 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 469895 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 11 Dec 2002 05:42:47 -0500 Received: from 12.27.183.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 11 Dec 2002 05:42:47 -0500 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <4B0HRWY4>; Wed, 11 Dec 2002 05:42:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2A102.57284A60" Message-ID: Date: Wed, 11 Dec 2002 05:44:54 -0500 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: FW: Comments: To: "anjalipatel1@YAHOO.COM" To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2A102.57284A60 Content-Type: text/plain; charset="iso-8859-1" Let me know if the following mail addressed the first topic you raised. For the BGP issues you may want to mail the IDR list instead. Thanks, Vishwas -----Original Message----- From: Manral, Vishwas [mailto:VishwasM@NETPLANE.COM] Sent: Sunday, December 08, 2002 4:01 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Hi Anju, 1) Well, if you want to reduce the size of the database in an Area, you could configure the area as either Stub or NSSA. You can check the draft http://www.ietf.org/internet-drafts/draft-ietf-ospf-nssa-update-11.txt and RFC2328 for details. Besides in OSPF there is a technique called DBOverflow, that allows handling of unanticipated database overflows - RFC1765. 2) You may like to see the flooding procedure Section 13, and section 10.3 neighbor state machine. The basic idea is that a DR/BDR is elected for each broadcast link, and non-DR routers form adjacencies with only DR/BDR. The DR-other sends LSUpdate packets to the address ALLDRRouters and DR/BDr send to ALLSPF routers. Thanks, Vishwas -----Original Message----- From: Anju Patel [mailto:anjalipatel1@YAHOO.COM] Sent: Sunday, December 08, 2002 7:55 AM To: OSPF@DISCUSS.MICROSOFT.COM Subject: hi I have couple of questions about ospf 1) what are the methods to reduce size of the LSP database in OSPF or IS-IS? 2) For OSPF routers that are connected to a multiple access medium- what is the method used to exchange the LSP-DB? 3) How does one connect an OSPF area that does not have a link to Area0? 4) what are the primary differences between RIP and OSPF? Thanks. ------_=_NextPart_001_01C2A102.57284A60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Let me know if the following mail addressed the = first topic you=20 raised.

For the=20 BGP issues you may want to mail the IDR list instead.

 

Thanks,

Vishwas

 -----Original Message-----
From: Manral, Vishwas=20 [mailto:VishwasM@NETPLANE.COM]
Sent: Sunday, December 08, = 2002 4:01=20 PM
To: OSPF@DISCUSS.MICROSOFT.COM
Subject:=20

Hi=20 Anju,
 
1)=20 Well, if you want to reduce the size of the database in an Area, you = could=20 configure the area as either Stub or NSSA.
You  can check the draft http://www.ietf.org/internet-drafts/draft-ietf-ospf-nssa-update-= 11.txt and=20 RFC2328 for details.
 
Besides in OSPF there is a technique called = DBOverflow,=20 that allows handling of unanticipated database overflows -=20 RFC1765.
 
2) You=20 may like to see the flooding procedure Section 13, and section 10.3 = neighbor=20 state machine. The basic idea is that a DR/BDR is elected for each = broadcast=20 link, and non-DR routers form adjacencies with only DR/BDR. The = DR-other sends=20 LSUpdate packets to the address ALLDRRouters and DR/BDr send to ALLSPF=20 routers.
 
Thanks,
Vishwas
 
-----Original=20 Message-----
From: Anju Patel=20 [mailto:anjalipatel1@YAHOO.COM]
Sent: Sunday, December 08, = 2002 7:55=20 AM
To: OSPF@DISCUSS.MICROSOFT.COM
Subject:=20

hi

I have couple of questions about ospf

1) what are the methods to reduce size of the LSP database in OSPF = or=20 IS-IS?

2) For OSPF routers that are connected to a multiple access = medium- what is=20 the method used to exchange the LSP-DB?

3) How does one connect an OSPF area that does not have a link to=20 Area0?

4) what are the primary differences between RIP and OSPF?

Thanks.

------_=_NextPart_001_01C2A102.57284A60-- From owner-ospf@DISCUSS.MICROSOFT.COM Wed Dec 11 08:08:50 2002 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 IAA03360 for ; Wed, 11 Dec 2002 08:08:50 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.0082CE29@cherry.ease.lsoft.com>; Wed, 11 Dec 2002 8:11:43 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 471036 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 11 Dec 2002 08:11:43 -0500 Received: from 194.250.197.211 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 11 Dec 2002 08:11:43 -0500 Received: from intranet.6wind.com (intranet [10.0.0.113]) by proxy.6wind.com (Postfix) with ESMTP id 725215B9 for ; Wed, 11 Dec 2002 14:20:43 +0100 (CET) Received: from 6wind.com (jardin.dev.6wind.com [10.16.0.239]) by intranet.6wind.com (Postfix) with ESMTP id E8E564AF for ; Wed, 11 Dec 2002 14:14:17 +0100 (CET) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3DF73AB7.90103@6wind.com> Date: Wed, 11 Dec 2002 14:16:39 +0100 Reply-To: Mailing List Sender: Mailing List From: Vincent Jardin Organization: http://www.6wind.com/ Subject: How could OPSFv3 support IPv4 ? To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit 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 ? 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 ? Regards, Vincent From owner-ospf@DISCUSS.MICROSOFT.COM Wed Dec 11 08:22:49 2002 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 IAA04068 for ; Wed, 11 Dec 2002 08:22:49 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.0082CE64@cherry.ease.lsoft.com>; Wed, 11 Dec 2002 8:25:42 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 471054 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 11 Dec 2002 08:25:42 -0500 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 11 Dec 2002 08:15:42 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03699; Wed, 11 Dec 2002 08:12:46 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200212111312.IAA03699@ietf.org> Date: Wed, 11 Dec 2002 08:12:45 -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-ospfv3-auth-00.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 : Authentication/Confidentiality for OSPFv3 Author(s) : M. Gupta, N. Melam Filename : draft-ietf-ospf-ospfv3-auth-00.txt Pages : 7 Date : 2002-12-9 This document describes means/mechanisms to provide authentication/confidentiality to OSPFv3 using IPv6 AH/ESP Extension Header. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-auth-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ospf-ospfv3-auth-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ospf-ospfv3-auth-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-12-9150238.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ospf-ospfv3-auth-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ospf-ospfv3-auth-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-12-9150238.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@DISCUSS.MICROSOFT.COM Wed Dec 11 08:22:54 2002 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 IAA04088 for ; Wed, 11 Dec 2002 08:22:53 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.0082CF7F@cherry.ease.lsoft.com>; Wed, 11 Dec 2002 8:25:47 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 471055 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 11 Dec 2002 08:25:47 -0500 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 11 Dec 2002 08:15:47 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03718; Wed, 11 Dec 2002 08:12:51 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200212111312.IAA03718@ietf.org> Date: Wed, 11 Dec 2002 08:12:50 -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-04.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF. Title : Hitless OSPF Restart Author(s) : J. Moy et al. Filename : draft-ietf-ospf-hitless-restart-04.txt Pages : 14 Date : 2002-12-9 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-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ospf-hitless-restart-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ospf-hitless-restart-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-12-9150247.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ospf-hitless-restart-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ospf-hitless-restart-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-12-9150247.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@DISCUSS.MICROSOFT.COM Wed Dec 11 09:15:16 2002 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 JAA06030 for ; Wed, 11 Dec 2002 09:15:16 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.0082CF5F@cherry.ease.lsoft.com>; Wed, 11 Dec 2002 9:18:09 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 471165 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 11 Dec 2002 09:18:08 -0500 Received: from 203.178.143.91 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 11 Dec 2002 09:18:08 -0500 Received: from localhost (localhost [127.0.0.1]) by plant.sfc.wide.ad.jp (Postfix) with ESMTP id 58C381C0C9; Wed, 11 Dec 2002 23:18:07 +0900 (JST) References: <3DF73AB7.90103@6wind.com> X-Mailer: Mew version 3.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20021211.231806.79707288.yasu@sfc.wide.ad.jp> Date: Wed, 11 Dec 2002 23:18:06 +0900 Reply-To: Mailing List Sender: Mailing List From: Yasuhiro Ohara Subject: Re: How could OPSFv3 support IPv4 ? Comments: To: jardin@6WIND.COM To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3DF73AB7.90103@6wind.com> Precedence: list Content-Transfer-Encoding: 7bit > 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 From owner-ospf@DISCUSS.MICROSOFT.COM Wed Dec 11 11:21:32 2002 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 LAA10876 for ; Wed, 11 Dec 2002 11:21:31 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.0082D395@cherry.ease.lsoft.com>; Wed, 11 Dec 2002 11:24:25 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 471420 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 11 Dec 2002 11:24:25 -0500 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 11 Dec 2002 11:14:25 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10588; Wed, 11 Dec 2002 11:11:26 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200212111611.LAA10588@ietf.org> Date: Wed, 11 Dec 2002 11:11:26 -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-srisuresh-ospf-te-04.txt Comments: cc: te-wg@ops.ietf.org, ccamp@ops.ietf.org 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 Internet Traffic Engineering Working Group of the IETF. Title : OSPF-TE: An experimental extension to OSPF for Traffic Engineering Author(s) : P. Srisuresh, P. Joseph Filename : draft-srisuresh-ospf-te-04.txt Pages : 45 Date : 2002-12-9 This document defines OSPF-TE, an experimental traffic engineering (TE) extension to the link-state routing protocol OSPF. New TE LSAs are designed to disseminate TE metrics within an autonomous System (AS) - intra-area as well as inter-area. An Autonomous System may consist of TE and non-TE nodes. Non-TE nodes are uneffected by the distribution of TE LSAs. A stand-alone TE Link State Database (TE-LSDB), separate from the native OSPF LSDB, is generated for the computation of TE circuit paths. OSPF-TE is also extendible to non-packet networks such as SONET/TDM and optical networks. A transition path is provided for those currently using [OPQLSA-TE] and wish to adapt OSPF-TE. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-srisuresh-ospf-te-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-srisuresh-ospf-te-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-srisuresh-ospf-te-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-12-9150220.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-srisuresh-ospf-te-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-srisuresh-ospf-te-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-12-9150220.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@DISCUSS.MICROSOFT.COM Wed Dec 11 11:26:50 2002 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 LAA11033 for ; Wed, 11 Dec 2002 11:26:50 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.0082D54E@cherry.ease.lsoft.com>; Wed, 11 Dec 2002 11:29:45 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 471461 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 11 Dec 2002 11:29:45 -0500 Received: from 12.27.183.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 11 Dec 2002 11:29:45 -0500 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <4B0HRXPA>; Wed, 11 Dec 2002 11:29:41 -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: Wed, 11 Dec 2002 11:31:48 -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 Yasu, I think you missed "Link-LSA" equivalents. I think they would be required too !!! 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 From owner-ospf@DISCUSS.MICROSOFT.COM Wed Dec 11 14:08:09 2002 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 OAA16712 for ; Wed, 11 Dec 2002 14:08:09 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.0082D867@cherry.ease.lsoft.com>; Wed, 11 Dec 2002 14:11:01 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 471825 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 11 Dec 2002 14:11:01 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 11 Dec 2002 14:11:01 -0500 Received: from redback.com (login002.redback.com [155.53.12.54]) by prattle.redback.com (Postfix) with ESMTP id E1E021E4061 for ; Wed, 11 Dec 2002 11:10:59 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; 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 Message-ID: <3DF78ECA.2000205@redback.com> Date: Wed, 11 Dec 2002 14:15:22 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: How could OPSFv3 support IPv4 ? To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit 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 Wed Dec 11 14:28:40 2002 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 OAA17543 for ; Wed, 11 Dec 2002 14:28:37 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.0082D9B1@cherry.ease.lsoft.com>; Wed, 11 Dec 2002 14:31:30 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 471876 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 11 Dec 2002 14:31:31 -0500 Received: from 194.250.197.211 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 11 Dec 2002 14:31:30 -0500 Received: by proxy.6wind.com (Postfix, from userid 12409) id 275D15AB; Wed, 11 Dec 2002 20:40:26 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by proxy.6wind.com (Postfix) with ESMTP id 224334C4 for ; Wed, 11 Dec 2002 20:40:26 +0100 (CET) X-X-Sender: jardin@proxy.ipv6.6wind.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: <20021211203621.C24991-100000@proxy.ipv6.6wind.com> Date: Wed, 11 Dec 2002 20:40:26 +0100 Reply-To: Mailing List Sender: Mailing List From: Vincent Jardin Subject: Re: How could OPSFv3 support IPv4 ? To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3DF78ECA.2000205@redback.com> Precedence: list 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 Wed Dec 11 19:05:38 2002 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 TAA26328 for ; Wed, 11 Dec 2002 19:05:38 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.0082E47D@cherry.ease.lsoft.com>; Wed, 11 Dec 2002 19:08:30 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 472476 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 11 Dec 2002 19:08:29 -0500 Received: from 216.136.131.150 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 11 Dec 2002 19:08:29 -0500 Received: from [47.81.25.149] by web11103.mail.yahoo.com via HTTP; Wed, 11 Dec 2002 16:08:28 PST MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20021212000828.9223.qmail@web11103.mail.yahoo.com> Date: Wed, 11 Dec 2002 16:08:28 -0800 Reply-To: Mailing List Sender: Mailing List From: Abhijit Kumbhare Subject: Receiving AS-external-LSAs with same LS ID - different net masks To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list If I receive 2 AS-external-LSAs with the same LS ID (which for some reason happens to be in a broadcast IP address format) - same advertising router but different masks - how do I handle it? For me a buggy neighbor router is advertising all the AS-external-LSAs with LS ID in the broadcast address format (this format in itself is not totally against the RFC - RFC 2328 appendix section E - algorithm for assigning LS IDs - does allow you to advertise in that format). The bug part is that is that it is sending 2 different LSAs with same LS ID. e.g. 208.144.0.0/17 and 208.144.96.0/19 routes have the same broadcast address 208.144.127.255. So this buggy router sends me the 2 LSAs with this LS ID. Should I install 2 different LSAs or only one? Which mask (smaller or longer)? I checked the same with a Cisco router - and it installed only one of them (smaller mask). I know it should not be advertised in this fashion (because the RFC says that LSAs are identified by LS ID, advertising router & LS type - then seq number, checksum, age in that order). __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com From owner-ospf@DISCUSS.MICROSOFT.COM Wed Dec 11 19:31:49 2002 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 TAA27228 for ; Wed, 11 Dec 2002 19:31:49 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.0082E36C@cherry.ease.lsoft.com>; Wed, 11 Dec 2002 19:34:43 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 472558 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 11 Dec 2002 19:34:42 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 11 Dec 2002 19:34:42 -0500 Received: from redback.com (login002.redback.com [155.53.12.54]) by prattle.redback.com (Postfix) with ESMTP id 263871E4CCB for ; Wed, 11 Dec 2002 16:34:41 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <20021212000828.9223.qmail@web11103.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3DF7DAA5.3000007@redback.com> Date: Wed, 11 Dec 2002 19:39:01 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Receiving AS-external-LSAs with same LS ID - different net masks To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Abhijit, I wouldn't bother try to handle a bug in someone else's implementation. You certainly shouldn't try to install multiple LSA since they are identified soly by the (type, lsid, advertising router) tuple. Hence I'd say that as long as you don't crash you are ok. Abhijit Kumbhare wrote: > If I receive 2 AS-external-LSAs with the same LS ID > (which for some reason happens to be in a broadcast IP > address format) - same advertising router but > different masks - how do I handle it? > > For me a buggy neighbor router is advertising all the > AS-external-LSAs with LS ID in the broadcast address > format (this format in itself is not totally against > the RFC - RFC 2328 appendix section E - algorithm for > assigning LS IDs - does allow you to advertise in that > format). The bug part is that is that it is sending 2 > different LSAs with same LS ID. > e.g. 208.144.0.0/17 and 208.144.96.0/19 routes have > the same broadcast address 208.144.127.255. So this > buggy router sends me the 2 LSAs with this LS ID. > > Should I install 2 different LSAs or only one? Which > mask (smaller or longer)? I checked the same with a > Cisco router - and it installed only one of them > (smaller mask). > > I know it should not be advertised in this fashion > (because the RFC says that LSAs are identified by LS > ID, advertising router & LS type - then seq number, > checksum, age in that order). > > > > __________________________________________________ > Do you Yahoo!? > Yahoo! Mail Plus - Powerful. Affordable. Sign up now. > http://mailplus.yahoo.com > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Wed Dec 11 20:45:45 2002 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 UAA28654 for ; Wed, 11 Dec 2002 20:45:44 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.0082E5C5@cherry.ease.lsoft.com>; Wed, 11 Dec 2002 20:48:36 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 472661 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 11 Dec 2002 20:48:36 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 11 Dec 2002 20:48:35 -0500 Received: from redback.com (login002.redback.com [155.53.12.54]) by prattle.redback.com (Postfix) with ESMTP id 20E66F607C for ; Wed, 11 Dec 2002 17:48:33 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------060101070807000309020003" Message-ID: <3DF7EBF4.6030205@redback.com> Date: Wed, 11 Dec 2002 20:52:52 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Updated WG Minutes To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list This is a multi-part message in MIME format. --------------060101070807000309020003 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I've gotten some corrections on from people on what they said and and thought it might make sense to re-post the 55th IETF WG Minutes. -- Acee --------------060101070807000309020003 Content-Type: text/plain; name="ietf55-ospf-wg-minutes.txt" Content-Disposition: inline; filename="ietf55-ospf-wg-minutes.txt" Content-Transfer-Encoding: 7bit OSPF WG meeting - Thursday 22nd of november - 15:00-17:00 ========================================================= Reported by: Dimitri Papadimitriou Document status (Acee Lindem and Rohit Dube): --------------- - RFC 3101 (Not-So-Stubby-Area) currently in final RFC editorship - Traffic engineering extensions to OSPF v2 (a.k.a. OSPF-TE) passed the working group last call (completed) - IETF wide last call to be issued soon. - Hitless restart - 04 version to be issued soon. Expect to have WG last call on this version. - Detecting Inactive Neighbors over OSPF Demand Circuits (draft-ietf-ospf-dc-05.txt) is pending and is pending wg chair comments. - OSPF Refresh and flooding reduction in stable topologies (draft-pillay-esnault-ospf-flooding-04.txt) needs a couple of edits but no significant changes. - Alternative OSPF ABR Implementations (draft-ietf-ospf-abr- alt-05.txt) in the comment cycle, it is pretty much done and the last call will be issued pretty quickly - mib-update-05.txt - May want to add the graceful restart capabilities Agenda bashing -------------- - Acee Lindem: Propose to move hitless restart after Kireeti presentation. - Kireeti Kompella: Agrees On the Agenda: ------------- 1) Rahul Aggarwal (10 Mins): Extensions to IS-IS and OSPF for Advertising Optional Router Capabilities http://www.ietf.org/internet-drafts/draft-raggarwa-igp-cap-01.txt Summary: -------- Several changes to this i-d since the last meeting. 1. Review of the motivation and benefits - MPLS-TE (and related) capability discovery mechanism - Network management and trouble shooting options are not extensible thus something generic needed 2. OSPF router information LSA - Optional router information LSA of type 4 and opaque ID 0 - Format of the TLV's in the body of the router info information lsa is the same as the TLV format used for the TE LSA's - Optional TLV must be included as the router capability sub-TLV (flags representing the capabilities), sub-TLV allows for adding additional information flags in the future depending on the needs 3. Router capability bits - see i-d 4. Conclusion - Application through router local policy - Flooding scope dependent on application Discussion: ----------- Acee Lindem: LSA option bits limited thus to be extended with the sub-TLV Rohit Dube: No mailing list comments so far. How will this fit into the charter? Right now there is not a specific item. Rahul Aggarwal: Proposal is made here to pass some information through the use of opaque LSA. Alex Zinin: Which part of this work is within the charter? Thus confrontation of this work wrt to the charter needs to be covered in addition to an IANA consideration section. Rahul Aggarwal: Agrees Alex Zinin: Might be a good idea to avoid FCFS allocation policy and go with Standards Action, IETF consensus, or at least expert review, we don't want to waste code points. Some value may also be allocated for experimentation. Tom Petch: Negotiation before exchange these opaque LSAs? as a first step? Rahul Aggarwal: Usage is a local matter, and also avoids the use of negotiation. Dimitri Papadimitriou: What are the TE mesh groups mentioned in this i-d? What is behind traffic-engineering? Are we sure that the underlying concepts are well cooked? What are the relation with TEWG, the current i-d covers one of the application of TE, but generic mechanism can also be considered that overlaps with GMPLS-OSPF. Rahul Aggarwal: Troubleshooting and specific application such as path computation server, may need additional work. Alex Zinin: Refers to the previous comments made during the previous meeting it seems that other WG participants prefers the usage of other mechanism to deliver such capability. Kireeti Kompella: Agrees Rohit Dube: People that oppose may not necessarily be here Rahul Aggarwal: Will send another mail for discussion in order to see where in which direction this i-d has to go after this meeting. ========================================================== 2) Kunihiro Ishiguro (15 Mins): OSPFv3 Traffic Engineering Extensions http://www.ietf.org/internet-drafts/draft-ishiguro-ospf-ospfv3-traffic-01.txt Summary: - Using the proposed framework, proposes an intra-area TE LSA with function code 10, flooding scope is area wide scope, u bit set to 1, thus if the router does not understand LSA it must be flooded anyway. - OSPFv3 TE TLV, katz i-d used as a base. TLV thus the router address and the link TLV are considered here for the OSPFv3 router LSA. Acee Lindem: There is an alternate proposal to be discussed thus comments to come after. Alex Zinin: Router-id in OSPFv2 TE extensions is a routable address, here you're changing it to a unique number only. What are the signalling-related implications? Kunihiro Ishiguro: Not sure at this moment and depends upon the implementation. Kireeti Kompella: Does IPv6 provide a addressable and/or reachable address? Kunihiro Ishiguro: Depends upon the implementation Kireeti Kompella: Take for instance, BGP over ipv6 what do you advertize as the next hop? Acee Lindem: It can be the router-id in IPv4. Kireeti Kompella: Router address TLV has been proposed to sync up ISIS and OSPF topologies, and as used in BGP today (to connect BGP with an incoming LSP request), the missing thing here is that links can be unnumbered and thus the point of the router id (the router address that it identifies) is that it needs to be globally unique or defined as unique wide address or sometimes it may be routable thus the same thing is needed with v6. Kunihiro Ishiguro: This comes from the traffic engineering implementation and or BGP, here a "stable IP address is not needed" but for traffic engineering purposes it seems to be. Alex Zinin: Seems that the confusion comes from the fact that even though the OSPF Router ID is defined as a unique 32-bit integer in OSPFv2, many implementations chose to use an IPv4 address for this purpose, while in OSPFv3 the 32-bit ID looses its possible address-related semantics. The logic in the draft seems to follow this. [Ishi agrees] However, the TE router-id is a separate notion. It is defined as a routable address in OSPFv2/IPv4, and we should stick with the same semantics in OSPFv3/IPv6. Acee Lindem: Questions about the semantic of the router-id. Kireeti Kompella: This is the router address TLV. ========================================================== 3) Acee Lindem (5 Mins): OSPF Hitless Restart Update http://www.ietf.org/internet-drafts/draft-ietf-ospf-hitless-restart-03.txt note: version -04.txt posted to list Summary: ------- - Hitless restart i-d of J. Moy, Acee Lindem acts as editor for this document and has an implementation for the interoperability testing. Padma Pillary-Ensault is also an author with an implementation. - Changes from 03->04 . Grace period restricted to the LSA refresh time . Alternative to saving crypto seq numbers in non-volatile storage . Alternate help mode termination (ignore LSA changes under configuration control) . Always flood to 224.0.0.5 in the case of unplanned restart which is important since a router loses the knwoledge of being previsouly elected as a designated router . Remove mospf, from future work and add less conservative helper termination - Proposed change: Add alternative to apply the grace LSA to all neighbor adjacencies for orinating router (Padma Pillay-Esnault). This only applies to the case where there are parallel adjacenncies - appears to be fully compatible as long as the grace LSA is flooded on all interfaces. Discussion: ---------- Acee Lindem: Thus ready for last call? Will re-issue the draft for comments and wait a couple weeks. Alex Zinin: Interoperability tests available? Acee Lindem: Redback is interoperable with Juniper (not tried the Moy's implementation), Force10 also has an implementation. Padma: Implementation between Juniper and Force10 tested. ========================================================== 4) Kireeti Kompella (10 Mins): OSPFv2 Opaques in OSPFv3 http://www.ietf.org/internet-drafts/draft-kompella-ospf-opaquev2-00.txt Summary: -------- 1. OSPFv2 compared to the OSPFv3 opaque LSA format 2. Proposal to migrate OSPFv2 opaque to OSPFv3, Use new OSPFv3 LSA type, everything else remains the same; the LSA ID is the same and the opaque LSA info is the same. 3. Issue with the backdoor problem - yes this is a backdoor but why it is a problem? 4. Related question? Is OSPFv3 for IPv6 (only) or an improvment of OSPFv2? Thus we should be able to run an IPv4 network with OSPFv3? - If so OSPFv3 is a superset of OSPFv2 - If not remove all the IPv4 prefix infromation from v3 Consider OSPFv3 as superset of OSPFv2 - Then we can migrate properly from v2 to v3 - If not all sorts of functions will break during the migration Alternative: - Define a new lsa function for each of the opaque LSA type: one for TE LSA, one for the grace LSA, etc. - What's the length of the opaque id? 24 or 32 bits? But this would break the migration 5. Conclusion Pros and cons for v2 opaque lsa in v3 - Pros: Code reuse v3 includes v2, migration - Cons: Theoritcal backdoor issue Pros and cons for translating opaque lsa one-by-one - Pro:? - Con: Would make the migration less pragmatic Next steps: We need to understand what's this backdoor problem is weight, the pro and cons and make a pragmatic decision (to have an opaque LSA ready code) Discussion: ---------- Alex Zinin: Questions about OSPFv3 for IPv4? Acee Lindem: Not described in the current RFC Alex Zinin: Let's not use this as the basement for the argument then. Kireeti Kompella: The inverse is done today Alex Zinin: Do we agree? Kireeti Kompella: Yes Alex Zinin: Why do you need "opaque type" in OSPFv3 LSAs? Kireeti Kompella: Opaque LSA, this is a v2 opaque LSA Alex Zinin: What not have a single level of numbering? Kireeti Kompella: This implies to change the code - do you know how long it takes? Alex Zinin: Yes Kireeti Kompella: The code to use is very simple, look at the opaque type... Alex Zinin: What's problem we try to solve? Kireeti Kompella: New opaque type in OSPFv3 and useful for OSPFv2 as well since I do not want to change my code for interoperability reasons Alex Zinin: No difference between the two proposals, thus which one to select Kireeti Kompella: Want to do it once (for all) Alex Zinin: With the proposal you grab the function code in OSPFv3, the only difference here is, v2 in v3, by doing that you create an overlap specification space and please think about the implication Rohit Dube: OSPFv3 for IPv6 is a different protocol from v2 in terms of a model it should be considered as different protocols. Kireeti Kompella: Thus OSPFv3 not used for IPv4 Alex Zinin: Thus we don't use it for discussion Kireeti Kompella: Make a statement, if the protocols are different then state this in the corrresponding document Rohit Dube: Could you clarify your point Kireeti Kompella: Since IPv4 in OSPFv3 is not specified, I will make the clarification in order to allow for that; by analogy, RSVP can use IPv6 identification over IPv4 everything is ready except the OSPFv2 document while people ask this from my side, thus this is a real problem and not a theoretical problem as the backdoor one. Alex Zinin: Final comment: leaving this up to the WG to decide which way to go, but concerned with this approach, as it will potentially create problems. Acee Lindem: This is not a brand new application thus I agree with Alex. Alex Zinin: Our job here is to make sure independent and interoperable implementations can be developed based on what we specify, I think this approach may result in underspecification. Kunihiro Ishiguro: type 9 is already used by v2, Kireeti Kompella: Types 9, 10, and 11 map in the value 22 in v3, meaning it is a v2 opaque LSA, but the backdoor problem is there anyway Rohit Dube: This problem will be further discussed on the mailing lists as well the respective merits of the two approaches. ========================================================== 5) Jerry Ash (10 Mins): Congestion Avoidance & Control for OSPF Networks http://www.ietf.org/internet-drafts/draft-ash-manral-ospf-congestion-control-00.txt Summary: -------- 1. Introduction: Draft addresses the problem of scalability; Evidence is failure experience, vendors analyzing their own OSPF implementations, and analysis of the LSA storms 2. Background and motivation 3. Failure experience: failure experience in 4/13/98 in the ATT frame relay network. 4. Proposed protocol mechanism: Signal a congestion state, to become to a specific OSPF protocol processing during the congestion detection, the neighbors will be notified about the slowdown and adjust the flooding rate. 5. Lot's of discussion on the list - is there a problem? We feel there is a problem. Initiate a debate on how to solve the problem, the protocol is complete as it is, and these problems will be resolved by having better implementations but operators asks for interoperable implementations this is the reason for these i-d's. Thus proposal to go beyond this and go to a procedure for that purpose? The proposed congestion response is analogous to the helper router response to a 'grace LSA' from a congested router in hitless restart. Concerning the approach of better coding? does it solves the problem but in the mean time we think that the better standard between vendors would be to solve these issues Discussion: ---------- Padma: Concerning the protocol extensions, grace LSA is not necessarily applicable since a restarting router is not a (necessarily) a congested router; are these to be considered as real protocol extensions (like for instance the throttling) or just more fine tuned implementations? Jerry Ash: The congested router would signal its congestion state before it saturates, this would reduce congestion by slowing down the neighbor LSAs sent to the congested router. These mechanisms are considered as protocol extensions: the neighbor response to the congestion notification is analogous to the helper router response to the 'grace LSA' from a congested router in hitless restart. Rohit Dube: Move discussions after the second presentation Acee Lindem: But keep track of the charter concerning the hello and ack prioritization. ========================================================== 6) Gagan L. Choudhury (10 Mins): Explicit Marking and Prioritized Treatment of Specific OSPF Packets for Faster Convergence and Improved Network Scalability and Stability http://www.ietf.org/internet-drafts/draft-ietf-ospf-scalability-02.txt Summary: ------- 1. Basic issue: failures in the network generating sustained CPU usage, LSA storms, and positive feedback loops. 2. Proposal: Priority for the hello and the ack's the question is how to deliver it, ask for having this as BCP, for instance diffserv codepoints for high priority and another for low priority. 3. Simulation study: Three priority scenarios, and two network scenarios, tested with 2 LSA scenarios. Show graphics on the non-converged LSAs Versus time as a function of the strength of the LSA storm (one curve for each LSA storm). There is an upper limit or threshold of LSA storm that the network can live with without causing sustained CPU congestion. Show table illustrating that in all cases priority for Hello increases the LSA storm threshold that the network can sustain. I In addition, if priority is given to LSA Ack as well then the LSA storm threshold is increased even further. Also, with priority for Hello the adjacency is not declared down even under heavy CPU congestion. 4. Proposal: Prioritization of Hello and LSA Ack is proposed as a BCP. One way of doing this would be to use one diffserv codepoint for higher priority OSPF packets and another diffserv codepoint for lower priority OSPF packets. Another way would be to look at the packet headers of incoming OSPF packets and queue higher and lower priority OSPF packets separately. Discussion: ---------- Gagan Choudhury: Should we move to the next one? Acee Lindem: yes ========================================================== 7) Gagan L. Choudhury (10 Mins) LSA Flooding Optimization Algorithms and their Simulation Study http://www.ietf.org/internet-drafts/draft-choudhury-manral-flooding-simulation-00.txt Summary: ------- 1. How to improve the LSA Storm threshold significantly? 2. Basic issue: in very large networks a large LSA storm may cause a sustained cpu congestion. 3. Flooding algos to be considered: - algo1: LSA flooding over all interfaces - algo2: LSA flooding over only one interface for parallel adjacencies - algo3: Full flooding only at Multipoint relays that are a subset of immediate neighbors Alex Zinin: algo3 does not guarantee the reliability of the flooding - algo4: flooding only along a minimum spanning tree - algo5: algo2 for non-te (topological) LSA's and - algo5: algo2 for LSAs carrying intra-area topology info and algo4 for "other" LSAs. A modified algo5 also considered that makes the flooding links for "other" LSAs survivable under single link failure and single node failure (using dual spanning trees) Alex Zinin: We can't use all of them or a selection 4. Simulation results: . Presentation of the five different cases each analyzed with the allowed LSA storm size . Observations on the flooding algorithms: Algorithm 2 gives substantial improvement over Algorithm 1, Algorithm 3 provides marginal improvement over Algorithm 2, Algorithms 4 and 5 provide substantial improvements over Algorithm 2. Modified Algorithm 5 is in between Algorithms 5 and 2. Algorithm 4 is not robust under failures and should not be considered. 5. Conclusion: algo2, algo5 and modified algo5 should be pursued further Discussion: ---------- Alex Zinin (as WG member): algo4 doesn't appear to be robust, can you explain in which context you propose it? Gagan Choudhury: In algo5 all LSAs carrying topology info would be flooded to all neighbors all the time. "Other" LSAs may not reach destination temporarily in case the minimum spanning tree is broken. They may be reflooded after the minimum spanning tree is repaired. Alex Zinin (as WG member): An ATM switch fails, while the IP router is unaware of the routing topology, how does it work? Gagan Choudhury: ATM Network is typically designed to be able to carry traffic under single link and single node failure. Our modified algo5 makes the flooding link for "other" LSAs survivable under single link and single node failures. Alex Zinin: We had a flooding-related mailing list a while ago where a similar discussion happened, an interesting aspect is that flooding optimizations are interesting when we have many topology changes, as this is when we have a lot to flood, but this also means that the changes are likely to hit both STs. Gagan Choudhury: During the failure, basic LSA's can carry the needed information. Alex Zinin: Which LSA's are flooded? Gagan Choudhury: Full flooding is only for the ones that are strictly needed. This includes "Router" and "Network" LSAs. "Other" LSAs are flooded over spanning tree. Alex Zinin: It is not really better to drop a type-4 or type-5 LSA as opposed to type-1 or type-2 (topology carrying), because if a router misses a prefix in its routing table, we'll have loops. Thinks if the WG is to consider flooding optimizations, it will be hard to get away without resync'ing, which may be heave with the current OSPF mechanisms, might need a passive mechanism like ISIS CSNPs. Acee Lindem: Basic flooding paradigm with proposed techniques seems reasonable but anything beyond this is questionable? Gagan Choudhury: Agrees Acee Lindem: Explicit marking, as specified in RFC 1812, says all OSPF packets should be sent at Internet Control level. If something new is proposed, it must be precisely specified. Gagan Choudhury: Agrees, BCP and explicit marking needs more details Rohit Dube: To be a bit stronger, priority of hellos, acks, use of other packet for the reset timer; all of these can be done without any protocol changes, to be abstracted and added as a WG i-d; everything else should be included in a separate document, Gagan Choudhury: Agrees Jerry Ash: Not only a BCP but also needs for an explicit notification mechanism. Rohit Dube: BCP talks about hellos and acks, and this seems to be agreed, everything requiring protocol changes (such as flooding) should be discussed separately. Jerry Ash: Proposed to start with the ECN (Explicit Congestion Notification) Rohit Dube: Propose a vote concering the ECN Acee Lindem: (describing the consensus) Clearly more people against. Padma Pillay-Esnault: Understand the congestion problems but most of these are related to bugs and implementation issues, the extensions are not really implementation-based solution since they can generate other problems; thus proposes to take them in offline discussions to be tackled by the implementation. Alex Zinin: EC notification and EC detection also needs mailing list discussion, people are afraid of specifying the implementation details, and oscillate between two extremes: only bits on the wire matter, vs implementation details. Alex thinks that specifying bits on the wire is not enough for routing protocols, as node-local processes affect behavior of the distributed system, however implementations details are too much. It is possible, though, to find the middle ground, see BGP route flap dampening for example. ========================================================== Rohit Dube: charter update =========================== Summary: ------- Charter update has been sent out on the list Selection criteria are as follows: - Rough consensus on the list - Technical quality of these i-ds - Urgency of the item - Charter proposal pending for a bit (queue up) Done things: ----------- - OSPF for IPv6 - NSSA update - OSPF-TE extensions To do list: ---------- - See proposal Dropped: ------- - MOSPF - OSPF flooding reduction Note: To be reconsidered in case of strong need Discussion: ---------- Alex Zinin: IPv6 meeting today on "site local" issues. Site border work not needed for now. Rohit Dube: Will submmit the chrter to these i-ds Acee Lindem: New items will be added or removed per evaluation criteria. ** end of the meeting ** --------------060101070807000309020003-- From owner-ospf@DISCUSS.MICROSOFT.COM Wed Dec 11 21:14:46 2002 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 VAA29291 for ; Wed, 11 Dec 2002 21:14:46 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.0082E907@cherry.ease.lsoft.com>; Wed, 11 Dec 2002 21:17:39 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 472723 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 11 Dec 2002 21:17:39 -0500 Received: from 203.178.143.91 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 11 Dec 2002 21:17:38 -0500 Received: from localhost (localhost [127.0.0.1]) by plant.sfc.wide.ad.jp (Postfix) with ESMTP id 1C85B1C17F; Thu, 12 Dec 2002 11:17:37 +0900 (JST) References: X-Mailer: Mew version 3.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20021212.111736.110462757.yasu@sfc.wide.ad.jp> Date: Thu, 12 Dec 2002 11:17:36 +0900 Reply-To: Mailing List Sender: Mailing List From: Yasuhiro Ohara Subject: Re: How could OPSFv3 support IPv4 ? Comments: To: VishwasM@NETPLANE.COM To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit right ;p) regards, yasu From: "Manral, Vishwas" Subject: Re: How could OPSFv3 support IPv4 ? Date: Wed, 11 Dec 2002 11:31:48 -0500 > Hi Yasu, > > I think you missed "Link-LSA" equivalents. I think they would be required > too !!! > > 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 From owner-ospf@DISCUSS.MICROSOFT.COM Thu Dec 12 00:21:22 2002 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 AAA03513 for ; Thu, 12 Dec 2002 00:21: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.0082EFCA@cherry.ease.lsoft.com>; Thu, 12 Dec 2002 0:11:56 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 473187 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 12 Dec 2002 00:11:56 -0500 Received: from 12.27.183.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 12 Dec 2002 00:11:56 -0500 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <4B0HRYW5>; Thu, 12 Dec 2002 00:11:55 -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: Thu, 12 Dec 2002 00:14:02 -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 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 Dec 12 01:13:04 2002 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 BAA04470 for ; Thu, 12 Dec 2002 01:13:04 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.0082F202@cherry.ease.lsoft.com>; Thu, 12 Dec 2002 1:15:57 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 473337 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 12 Dec 2002 01:15:56 -0500 Received: from 12.27.183.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 12 Dec 2002 01:15:56 -0500 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <4B0HRYZH>; Thu, 12 Dec 2002 01:15:56 -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: Thu, 12 Dec 2002 01:17:49 -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 Vincent, Actually thinking of it, if we want another bit v4-bit in the router LSA we can have mixed topology in an area(i.e. some routers supporting IPv4 alone, some supporting IPv6 alone and some supporting both). In that case we would have to do seperate SPF per area for each protocol supported. Thanks, Vishwas -----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 Dec 12 04:51:10 2002 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 EAA18167 for ; Thu, 12 Dec 2002 04:51:10 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.0082F647@cherry.ease.lsoft.com>; Thu, 12 Dec 2002 4:54:04 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 473720 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 12 Dec 2002 04:54:03 -0500 Received: from 194.250.197.211 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 12 Dec 2002 04:54:03 -0500 Received: from intranet.6wind.com (intranet [10.0.0.113]) by proxy.6wind.com (Postfix) with ESMTP id 878E25B0 for ; Thu, 12 Dec 2002 11:03:06 +0100 (CET) Received: from 6wind.com (jardin.dev.6wind.com [10.16.0.239]) by intranet.6wind.com (Postfix) with ESMTP id 9D4231F4 for ; Thu, 12 Dec 2002 10:56:40 +0100 (CET) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3DF85DE4.7060800@6wind.com> Date: Thu, 12 Dec 2002 10:59:00 +0100 Reply-To: Mailing List Sender: Mailing List From: Vincent Jardin Organization: http://www.6wind.com/ Subject: Re: How could OPSFv3 support IPv4 ? To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi Vishwas, >Actually thinking of it, if we want another bit v4-bit in the router LSA we >can have mixed topology in an area(i.e. some routers supporting IPv4 alone, >some supporting IPv6 alone and some supporting both). In that case we would >have to do seperate SPF per area for each protocol supported. > It depends. For example, it could be optimized: - if all the routers supports IPv4 and IPv6, one SPF might be enough - if one router does not support IPv4 within the area, maybe 2 full SPF computations are required Regards, Vincent From owner-ospf@DISCUSS.MICROSOFT.COM Thu Dec 12 04:54:33 2002 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 EAA18201 for ; Thu, 12 Dec 2002 04:54:33 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.0082F578@cherry.ease.lsoft.com>; Thu, 12 Dec 2002 4:57:28 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 473731 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 12 Dec 2002 04:57:28 -0500 Received: from 12.27.183.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 12 Dec 2002 04:57:28 -0500 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <4B0HRZAS>; Thu, 12 Dec 2002 04:57:28 -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: Thu, 12 Dec 2002 04:59:35 -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 Vincent, Agree. That is what I meant when I said "if we want another bit v4-bit in the router LSA we can have mixed topology in an area(i.e. some routers supporting IPv4 alone, some supporting IPv6 alone and some supporting both). In that case we would have to do seperate SPF per area for each protocol supported." If all routers support packet forwarding for all protocols supported we would not require seperate SPF for them. Thanks, Vishwas -----Original Message----- From: Vincent Jardin [mailto:jardin@6WIND.COM] Sent: Thursday, December 12, 2002 3:29 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: How could OPSFv3 support IPv4 ? Hi Vishwas, >Actually thinking of it, if we want another bit v4-bit in the router LSA we >can have mixed topology in an area(i.e. some routers supporting IPv4 alone, >some supporting IPv6 alone and some supporting both). In that case we would >have to do seperate SPF per area for each protocol supported. > It depends. For example, it could be optimized: - if all the routers supports IPv4 and IPv6, one SPF might be enough - if one router does not support IPv4 within the area, maybe 2 full SPF computations are required Regards, Vincent From owner-ospf@DISCUSS.MICROSOFT.COM Thu Dec 12 10:12:33 2002 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 KAA26625 for ; Thu, 12 Dec 2002 10:12:32 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.0082FCCC@cherry.ease.lsoft.com>; Thu, 12 Dec 2002 10:15:26 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 475436 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 12 Dec 2002 10:15:25 -0500 Received: from 216.136.173.59 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 12 Dec 2002 10:15:25 -0500 Received: from 12-234-140-126.client.attbi.com (HELO suresh) (srisuresh@12.234.140.126 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 12 Dec 2002 15:15:24 -0000 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_1DC8_01C2A1AE.C6E51AC0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Message-ID: Date: Thu, 12 Dec 2002 07:19:15 -0800 Reply-To: Mailing List Sender: Mailing List From: Pyda Srisuresh Subject: FW: I-D ACTION:draft-srisuresh-ospf-te-04.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_1DC8_01C2A1AE.C6E51AC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit -----Original Message----- From: Mailing List [mailto:OSPF@DISCUSS.MICROSOFT.COM]On Behalf Of Internet-Drafts@IETF.ORG Sent: Wednesday, December 11, 2002 8:11 AM To: OSPF@DISCUSS.MICROSOFT.COM Subject: I-D ACTION:draft-srisuresh-ospf-te-04.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Traffic Engineering Working Group of the IETF. Title : OSPF-TE: An experimental extension to OSPF for Traffic Engineering Author(s) : P. Srisuresh, P. Joseph Filename : draft-srisuresh-ospf-te-04.txt Pages : 45 Date : 2002-12-9 This document defines OSPF-TE, an experimental traffic engineering (TE) extension to the link-state routing protocol OSPF. New TE LSAs are designed to disseminate TE metrics within an autonomous System (AS) - intra-area as well as inter-area. An Autonomous System may consist of TE and non-TE nodes. Non-TE nodes are uneffected by the distribution of TE LSAs. A stand-alone TE Link State Database (TE-LSDB), separate from the native OSPF LSDB, is generated for the computation of TE circuit paths. OSPF-TE is also extendible to non-packet networks such as SONET/TDM and optical networks. A transition path is provided for those currently using [OPQLSA-TE] and wish to adapt OSPF-TE. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-srisuresh-ospf-te-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-srisuresh-ospf-te-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-srisuresh-ospf-te-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------=_NextPart_000_1DC8_01C2A1AE.C6E51AC0 Content-Type: Message/External-body; name="ATT07565.dat" Content-Disposition: attachment; filename="ATT07565.dat" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2002-12-9150220.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-srisuresh-ospf-te-04.txt ------=_NextPart_000_1DC8_01C2A1AE.C6E51AC0 Content-Type: Message/External-body; name="draft-srisuresh-ospf-te-04.txt" Content-Disposition: attachment; filename="draft-srisuresh-ospf-te-04.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2002-12-9150220.I-D@ietf.org> ------=_NextPart_000_1DC8_01C2A1AE.C6E51AC0-- From owner-ospf@DISCUSS.MICROSOFT.COM Thu Dec 12 10:33:11 2002 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 KAA27504 for ; Thu, 12 Dec 2002 10:33:10 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.0082FCB6@cherry.ease.lsoft.com>; Thu, 12 Dec 2002 10:36:04 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 475499 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 12 Dec 2002 10:36:03 -0500 Received: from 216.136.174.113 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 12 Dec 2002 10:36:03 -0500 Received: from 12-234-140-126.client.attbi.com (HELO suresh) (srisuresh@12.234.140.126 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 12 Dec 2002 15:36:02 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Message-ID: Date: Thu, 12 Dec 2002 07:39:52 -0800 Reply-To: Mailing List Sender: Mailing List From: Pyda Srisuresh Subject: Re: draft-srisuresh-ospf-te-04.txt Comments: To: Rohit Dube Comments: cc: pjoseph@Force10Networks.com, acee@redback.com, zinin@psg.com, fenner@research.att.com To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <200212121338.IAA20768@bigbird.xebeo.com> Precedence: list Content-Transfer-Encoding: 7bit Rohit, I am taking te-wg off the mail list as the following discussion pertains to OSPF WG only. I was not present at the Atlanta IETF. But, I looked at the work group minutes posted on 12/11. The minutes say that MOSPF and OSPF-flooding reduction are beign dropped from the charter. I saw no mention of alternate ospf-te proposals from being dropped. Same thing goes for the mailing list. I am not aware of any discussion on the list suggesting alternate ospf-te proposals being dropped from the charter. If the WG charter is to cover the OSPF for TE and non-TE, the charter must include discussion of multiple ospf-te proposals. If the charter is written to imply that it covers Opaque LSA based TE extensions only and no alternate ospf-te proposals, then such an implication is not apparent and should be discussed. katz-yeung draft has several shortcomings, hasnt completed the IETF last call and is not an RFC yet. To presuppose the katz-yeung draft to be the only viable TE protocol and to exclude alternate proposals is a mistake, IMHO. Would appreciate your posting the exact wording of the updated charter for the WG on the mailing list. regards, suresh -----Original Message----- From: Rohit Dube [mailto:rohit@xebeo.com] Sent: Thursday, December 12, 2002 5:38 AM To: Jim Boyle Cc: Pyda Srisuresh; te-wg@ops.ietf.org; pjoseph@Force10Networks.com; acee@redback.com; zinin@psg.com; fenner@research.att.com Subject: Re: draft-srisuresh-ospf-te-04.txt FWIW, The katz-yeung ospf-te draft is scheduled to go to ietf-wide last call (if it hasn't already). The ospf-wg charter was recently debated on the ospf mailing wrt an update. It was also discussed extensively by me, Acee and the routing ADs and at the ospf-wg meeting in atlanta. The charter agreed upon does not include any work-item for alternate ospf-te proposals. Regards, --rohit. On Wed, 11 Dec 2002 20:08:20 -0500 (EST) Jim Boyle writes: => =>So it is more of a contribution to the OSPF WG, not the TEWG? =>I'll ask ietf-secretary to make the corresponding changes. =>You might want to forward the announce message to OSPF WG. => =>thanks, => =>Jim From owner-ospf@DISCUSS.MICROSOFT.COM Thu Dec 12 10:57:47 2002 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 KAA28485 for ; Thu, 12 Dec 2002 10:57:46 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.0082FD27@cherry.ease.lsoft.com>; Thu, 12 Dec 2002 11:00:41 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 475588 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 12 Dec 2002 11:00:40 -0500 Received: from 204.192.44.242 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 12 Dec 2002 11:00:40 -0500 Received: (qmail 31332 invoked from network); 12 Dec 2002 16:00:40 -0000 Received: from bigbird.xebeo.com (192.168.0.21) by lxmail.xebeo.com with SMTP; 12 Dec 2002 16:00:40 -0000 Received: from bigbird.xebeo.com (localhost.localdomain [127.0.0.1]) by bigbird.xebeo.com (8.9.3/8.9.3) with ESMTP id LAA22016; Thu, 12 Dec 2002 11:00:39 -0500 X-Mailer: exmh version 2.1.1 10/15/1999 Mime-Version: 1.0 Content-Type: multipart/mixed ; boundary="==_Exmh_21146629350" Message-ID: <200212121600.LAA22016@bigbird.xebeo.com> Date: Thu, 12 Dec 2002 11:00:39 -0500 Reply-To: Mailing List Sender: Mailing List From: Rohit Dube Subject: Re: draft-srisuresh-ospf-te-04.txt Comments: To: srisuresh@yahoo.com Comments: cc: pjoseph@Force10Networks.com, zinin@psg.com, fenner@research.att.com To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Message from "Pyda Srisuresh" of "Thu, 12 Dec 2002 07:39:52 PST." Precedence: list This is a multipart MIME message. --==_Exmh_21146629350 Content-Type: text/plain; charset=us-ascii Hello, Some comments inline. On Thu, 12 Dec 2002 07:39:52 -0800 "Pyda Srisuresh" writes: =>Rohit, => =>I am taking te-wg off the mail list as the following =>discussion pertains to OSPF WG only. => =>I was not present at the Atlanta IETF. But, I looked =>at the work group minutes posted on 12/11. The minutes =>say that MOSPF and OSPF-flooding reduction are beign dropped =>from the charter. I saw no mention of alternate ospf-te =>proposals from being dropped. This is correct. I should have been more precise in what I said - I was trying to convey that we have a broadly agreed upon charter. While the charter was being discussed on the list or at WG meeting in Atlanta there was no voiced-concern about not including alternate ospf-te proposals in the charter. As Acee and I explained at the Atlanta meeting, before picking up new charter items, we would like to see interest (and public comment) from deployers. Could you point to such interest in the alternate draft - since an alternate ospf-te proposal would have to be a new charter item at this point. => =>Same thing goes for the mailing list. I am not aware of any =>discussion on the list suggesting alternate ospf-te proposals =>being dropped from the charter. Correct again. Hope my comment above clarifies what I meant. => =>If the WG charter is to cover the OSPF for TE and non-TE, the =>charter must include discussion of multiple ospf-te proposals. =>If the charter is written to imply that it covers Opaque LSA =>based TE extensions only and no alternate ospf-te proposals, then =>such an implication is not apparent and should be discussed. =>katz-yeung draft has several shortcomings, hasnt completed the =>IETF last call and is not an RFC yet. To presuppose the =>katz-yeung draft to be the only viable TE protocol and to =>exclude alternate proposals is a mistake, IMHO. You are welcome to argue this out on the mailing list. In its favour, katz-yeung has multiple (probably > 10 by now) implementations many of which are known to inter-operate and are deployed in live networks. While I would agree with you that there are shortcomings in katz-yeung, any competing draft has to be more than a little bit better to overcome the experience implementors and deployers have obtained with this solution. => =>Would appreciate your posting the exact wording of the updated =>charter for the WG on the mailing list. Attached below. I have requested the ADs to post this on the ospf-wg web page so that it is easier to access. => =>regards, =>suresh => Best, --rohit. --==_Exmh_21146629350 Content-Type: text/plain ; name="charter.txt"; charset=us-ascii Content-Description: charter.txt Content-Disposition: attachment; filename="charter.txt" Goals and Milestones: Done Submit OSPF for IPv6 to IESG for consideration as a Standard. Done Update the OSPF NSSA option specified in RFC 1587 and submit to IESG for consideration as a Proposed Standard. Done Develop Traffic Engineering extensions for OSPFv2 and submit it to the IESG as a Proposed Standard. MAR 03 Submit to IESG a document which updates RFC 1793 allowing detection of demand circuit neighbors whose OSPF process has exited. MAR 03 Submit to IESG a BCP advocating that OSPF LSA refreshes be spread out over time MAR 03 Submit to IESG a BCP advocating that OSPF Hellos be given preference over other OSPF control traffic. MAR 03 Document Alternative ABR implementations and submit to IESG as an Informational RFC. MAR 03 Develop a hitless restart mechanism for OSPF and submit it to the IESG as a Proposed Standard. NOV 03 Update OSPFv2 MIB and submit to IESG as a Standard, replacing RFC 1850 NOV 03 Extend the hitless restart mechanism to OSPFv3 and submit it to the IESG as a Proposed Standard. NOV 03 Develop Traffic Engineering extensions for OSPFv3 and submit it to the IESG as a Proposed Standard. NOV 03 Develop OSPF for IPv6 MIB and submit to IESG for consideration as a Proposed Standard. NOV 03 Specify IPSEC usage with OSPFv3 and submit to IESG for consideration as a Proposed Standard. Dropped OCT 01 Update MOSPF specification with bug fixes and changes required by RFC 2328. Submit to IESG as Draft Standard JAN 02 Develop pruning support for MOSPF, allowing it to be used in a transit multicast domain and with IGMPv3. Submit to IESG as Proposed Standard JAN 02 Develop mechanisms to reduce OSPF flooding traffic in highly connected network topologies. Submit to IESG as Proposed Standard. $Id: charter.txt,v 1.15 2002/11/22 19:27:15 rohit Exp rohit $ --==_Exmh_21146629350-- From owner-ospf@DISCUSS.MICROSOFT.COM Thu Dec 12 11:05:28 2002 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 LAA28983 for ; Thu, 12 Dec 2002 11:05:28 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.0082FD8A@cherry.ease.lsoft.com>; Thu, 12 Dec 2002 11:08:23 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 475571 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 12 Dec 2002 11:08:23 -0500 Received: from 203.199.83.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 12 Dec 2002 10:58:22 -0500 Received: (qmail 27568 invoked by uid 510); 12 Dec 2002 15:57:59 -0000 Received: from unknown (203.197.138.194) by rediffmail.com via HTTP; 12 dec 2002 15:57:59 -0000 MIME-Version: 1.0 Content-type: text/plain; format=flowed Content-Disposition: inline Message-ID: <20021212155759.27567.qmail@webmail26.rediffmail.com> Date: Thu, 12 Dec 2002 15:57:59 -0000 Reply-To: Mailing List Sender: Mailing List From: Rajesh G Subject: Router link origination when interface is up To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi, When ospf is enabled on an interface in which we already have valid DR and BDR for the network, we face the following problem. As soon as the interface comes up a router LSA is generated stating the network as stub (as we don't have knowledge about other routers in the n/w). After some time we get a hello packet from a neighbor giving us the DR and BDR for the n/w which we accept. Here we do not re-build our own router LSA. Even if we run the DR election and dont find any change in the DR status, we still don't rebuild our router LSA. So we advertise the n/w as stub link, till the refresh interval. What could be the possible solution to avoid this problem. My guess is that we should not originate our router LSA till we are sure about the nature of the network (either our wait timer expires or we get a Hello with a valid DR and BDR on the n/w). Is this correct? please give your inputs. TIA, Rajesh From owner-ospf@DISCUSS.MICROSOFT.COM Thu Dec 12 11:19:59 2002 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 LAA29669 for ; Thu, 12 Dec 2002 11:19:59 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.0082FD6B@cherry.ease.lsoft.com>; Thu, 12 Dec 2002 11:22:34 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 475653 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 12 Dec 2002 11:22:34 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 12 Dec 2002 11:22:34 -0500 Received: from redback.com (login001.redback.com [155.53.12.18]) by prattle.redback.com (Postfix) with ESMTP id D258ACAB69 for ; Thu, 12 Dec 2002 08:22:32 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <20021212155759.27567.qmail@webmail26.rediffmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3DF8B8C4.4010204@redback.com> Date: Thu, 12 Dec 2002 11:26:44 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Router link origination when interface is up To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Rajesh G wrote: > Hi, > > When ospf is enabled on an interface in which we already > have valid DR and BDR for the network, we face the following > problem. As soon as the interface comes up a router LSA is > generated stating the network as stub (as we don't have knowledge > about other routers in the n/w). After some time we get a hello > packet from a neighbor giving us the DR and BDR for the n/w which > we accept. Here we do not re-build our own router LSA. Even if we > run the DR election and dont find any change in the DR status, we > still don't rebuild our router LSA. So we advertise the n/w as > stub link, till the refresh interval. > > What could be the possible solution to avoid this problem. > My guess is that we should not originate our router LSA till we > are sure about the nature of the network (either our wait timer > expires or we get a Hello with a valid DR and BDR on the n/w). Is > this correct? please give your inputs. Rajesh - don't delay origination. You should re-originate your router LSA when you go to FULL state with the DR. Look at section 12.4 in RFC 2328. > > TIA, > > Rajesh > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Thu Dec 12 11:50:25 2002 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 LAA01434 for ; Thu, 12 Dec 2002 11:50:25 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.0082FE7D@cherry.ease.lsoft.com>; Thu, 12 Dec 2002 11:53:20 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 475758 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 12 Dec 2002 11:53:20 -0500 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 12 Dec 2002 11:53:20 -0500 Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id gBCGrJS27077 for ; Thu, 12 Dec 2002 08:53:19 -0800 (PST) (envelope-from kireeti@juniper.net) Received: (from kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) id gBCGrJS25424 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 12 Dec 2002 08:53:19 -0800 (PST) (envelope-from kireeti) Message-ID: <200212121653.gBCGrJS25424@kummer.juniper.net> Date: Thu, 12 Dec 2002 08:53:19 -0800 Reply-To: Mailing List Sender: Mailing List From: Kireeti Kompella Subject: Re: draft-srisuresh-ospf-te-04.txt To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Precedence: list > If the WG charter is to cover the OSPF for TE and non-TE, the > charter must include discussion of multiple ospf-te proposals. I don't buy this argument. There is no reason to discuss multiple proposals for *every* work item. In particular, the MPLS and CCAMP WGs henceforth will discuss only one TE signaling protocol (and one non-TE signaling protocol). If there are deficiencies in the current TE document *and there is WG consensus on that* (the authors' opinions alone don't suffice), then one can consider alternative proposals. Kireeti. From owner-ospf@DISCUSS.MICROSOFT.COM Thu Dec 12 17:20:35 2002 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 RAA15165 for ; Thu, 12 Dec 2002 17:20:35 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00830AF8@cherry.ease.lsoft.com>; Thu, 12 Dec 2002 17:23:29 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 476687 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 12 Dec 2002 17:23:28 -0500 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 12 Dec 2002 17:23:28 -0500 Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id gBCMNSS58924 for ; Thu, 12 Dec 2002 14:23:28 -0800 (PST) (envelope-from kireeti@juniper.net) Received: (from kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) id gBCMNSZ27071 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 12 Dec 2002 14:23:28 -0800 (PST) (envelope-from kireeti) Message-ID: <200212122223.gBCMNSZ27071@kummer.juniper.net> Date: Thu, 12 Dec 2002 14:23:28 -0800 Reply-To: Mailing List Sender: Mailing List From: Kireeti Kompella Subject: Re: Updated WG Minutes To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3DF7EBF4.6030205@redback.com> Precedence: list Hi Acee, > I've gotten some corrections on from people on what they said and and > thought it might make sense to re-post the 55th IETF WG Minutes. Here are some more corrections/clarifications, prefaced by >>>. Kireeti. OSPF WG meeting - Thursday 22nd of november - 15:00-17:00 ========================================================= Reported by: Dimitri Papadimitriou 2) Kunihiro Ishiguro (15 Mins): OSPFv3 Traffic Engineering Extensions (snipped) Acee Lindem: Questions about the semantic of the router-id. Kireeti Kompella: This is the router address TLV. >>> A Router Address is a stable, routable address. A router ID >>> may not be routable. ========================================================== 4) Kireeti Kompella (10 Mins): OSPFv2 Opaques in OSPFv3 http://www.ietf.org/internet-drafts/draft-kompella-ospf-opaquev2-00.txt Next steps: We need to understand what's this backdoor problem is weight, the pro and cons and make a pragmatic decision (to have an opaque LSA ready code) >>> Next steps: We need to understand what's this backdoor >>> problem is, weigh the pros and cons and make a pragmatic >>> decision (to have an opaque LSA ready code) Discussion: ---------- Alex Zinin: Questions about OSPFv3 for IPv4? Acee Lindem: Not described in the current RFC Alex Zinin: Let's not use this as the basement >>> as the basis for the argument then. Kireeti Kompella: The inverse is done today >>> I can't remember what I said here. Alex Zinin: Do we agree? Kireeti Kompella: Yes Alex Zinin: Why do you need "opaque type" in OSPFv3 LSAs? Kireeti Kompella: Opaque LSA, this is a v2 opaque LSA Alex Zinin: What not have a single level of numbering? Kireeti Kompella: This implies to change the code - do you know how long it takes? Alex Zinin: Yes Kireeti Kompella: The code to use is very simple, look at the opaque type... Alex Zinin: What's problem we try to solve? Kireeti Kompella: New opaque type in OSPFv3 and useful for OSPFv2 as well since I do not want to change my code for interoperability reasons Alex Zinin: No difference between the two proposals, thus which one to select Kireeti Kompella: Want to do it once (for all) Alex Zinin: With the proposal you grab the function code in OSPFv3, the only difference here is, v2 in v3, by doing that you create an overlap specification space and please think about the implication Rohit Dube: OSPFv3 for IPv6 is a different protocol from v2 in terms of a model it should be considered as different protocols. Kireeti Kompella: Thus OSPFv3 not used for IPv4 >>> Thus OSPFv3 is not to be used for IPv4 Alex Zinin: Thus we don't use it for discussion Kireeti Kompella: Make a statement, if the protocols are different then state this in the corrresponding document Rohit Dube: Could you clarify your point Kireeti Kompella: Since IPv4 in OSPFv3 is not specified, I will make the clarification in order to allow for that; by analogy, RSVP can use IPv6 identification over IPv4 >>> RSVP can use IPv6 addresses (for ERO) over an IPv4 backbone everything is ready except the OSPFv2 document while people ask this from my side, thus this is a real problem and not a theoretical problem as the backdoor one. Alex Zinin: Final comment: leaving this up to the WG to decide which way to go, but concerned with this approach, as it will potentially create problems. Acee Lindem: This is not a brand new application thus I agree with Alex. Alex Zinin: Our job here is to make sure independent and interoperable implementations can be developed based on what we specify, I think this approach may result in underspecification. Kunihiro Ishiguro: type 9 is already used by v2, Kireeti Kompella: Types 9, 10, and 11 map in the value 22 in v3, meaning it is a v2 opaque LSA, but >>> value 22 is just an example! the backdoor problem is there anyway Rohit Dube: This problem will be further discussed on the mailing lists as well the respective merits of the two approaches. From owner-ospf@DISCUSS.MICROSOFT.COM Thu Dec 12 17:29:25 2002 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 RAA15400 for ; Thu, 12 Dec 2002 17:29:25 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00830DFD@cherry.ease.lsoft.com>; Thu, 12 Dec 2002 17:32:19 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 476802 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 12 Dec 2002 17:32:19 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 12 Dec 2002 17:32:17 -0500 Received: from redback.com (login003.redback.com [155.53.12.55]) by prattle.redback.com (Postfix) with ESMTP id 3C8821E8658 for ; Thu, 12 Dec 2002 14:32:17 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <200212122223.gBCMNSZ27071@kummer.juniper.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3DF90F69.7030107@redback.com> Date: Thu, 12 Dec 2002 17:36:25 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Updated WG Minutes To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Anybody else???? I should have know that if I sent them in I'd get some additional comments. Thanks, Acee Kireeti Kompella wrote: > Hi Acee, > > >>I've gotten some corrections on from people on what they said and and >>thought it might make sense to re-post the 55th IETF WG Minutes. > > > Here are some more corrections/clarifications, prefaced by >>>. > > Kireeti. > > OSPF WG meeting - Thursday 22nd of november - 15:00-17:00 > ========================================================= > Reported by: Dimitri Papadimitriou > > 2) Kunihiro Ishiguro (15 Mins): OSPFv3 Traffic Engineering Extensions > > (snipped) > > Acee Lindem: Questions about the semantic of the router-id. > > Kireeti Kompella: This is the router address TLV. > > >>>>A Router Address is a stable, routable address. A router ID >>>>may not be routable. >>> > > ========================================================== > > 4) Kireeti Kompella (10 Mins): OSPFv2 Opaques in OSPFv3 > http://www.ietf.org/internet-drafts/draft-kompella-ospf-opaquev2-00.txt > > Next steps: We need to understand what's this backdoor > problem is weight, the pro and cons and make a pragmatic > decision (to have an opaque LSA ready code) > > >>>>Next steps: We need to understand what's this backdoor >>>>problem is, weigh the pros and cons and make a pragmatic >>>>decision (to have an opaque LSA ready code) >>> > > Discussion: > ---------- > > Alex Zinin: Questions about OSPFv3 for IPv4? > > Acee Lindem: Not described in the current RFC > > Alex Zinin: Let's not use this as the basement > > >>>>as the basis >>> > > for the argument then. > > Kireeti Kompella: The inverse is done today > > >>>>I can't remember what I said here. >>> > > Alex Zinin: Do we agree? > > Kireeti Kompella: Yes > > Alex Zinin: Why do you need "opaque type" in OSPFv3 > LSAs? > > Kireeti Kompella: Opaque LSA, this is a v2 opaque LSA > > Alex Zinin: What not have a single level of numbering? > > Kireeti Kompella: This implies to change the code - do > you know how long it takes? > > Alex Zinin: Yes > > Kireeti Kompella: The code to use is very simple, look > at the opaque type... > > Alex Zinin: What's problem we try to solve? > > Kireeti Kompella: New opaque type in OSPFv3 and useful for > OSPFv2 as well since I do not want to change my code for > interoperability reasons > > Alex Zinin: No difference between the two proposals, thus > which one to select > > Kireeti Kompella: Want to do it once (for all) > > Alex Zinin: With the proposal you grab the function code > in OSPFv3, the only difference here is, v2 in v3, by doing > that you create an overlap specification space and please > think about the implication > > Rohit Dube: OSPFv3 for IPv6 is a different protocol from v2 > in terms of a model it should be considered as different > protocols. > > Kireeti Kompella: Thus OSPFv3 not used for IPv4 > > >>>>Thus OSPFv3 is not to be used for IPv4 >>> > > Alex Zinin: Thus we don't use it for discussion > > Kireeti Kompella: Make a statement, if the protocols are > different then state this in the corrresponding document > > Rohit Dube: Could you clarify your point > > Kireeti Kompella: Since IPv4 in OSPFv3 is not specified, > I will make the clarification in order to allow for that; > by analogy, RSVP can use IPv6 identification over IPv4 > > >>>>RSVP can use IPv6 addresses (for ERO) over an IPv4 backbone >>> > > everything is ready except the OSPFv2 document while > people ask this from my side, thus this is a real problem > and not a theoretical problem as the backdoor one. > > Alex Zinin: Final comment: leaving this up to the WG > to decide which way to go, but concerned with this > approach, as it will potentially create problems. > > Acee Lindem: This is not a brand new application thus > I agree with Alex. > > Alex Zinin: Our job here is to make sure independent > and interoperable implementations can be developed based > on what we specify, I think this approach may result > in underspecification. > > Kunihiro Ishiguro: type 9 is already used by v2, > > Kireeti Kompella: Types 9, 10, and 11 map in the > value 22 in v3, meaning it is a v2 opaque LSA, but > > >>>>value 22 is just an example! >>> > > the backdoor problem is there anyway > > Rohit Dube: This problem will be further discussed on > the mailing lists as well the respective merits of the > two approaches. > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Thu Dec 12 19:57:35 2002 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 TAA19312 for ; Thu, 12 Dec 2002 19:57:35 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.0083167C@cherry.ease.lsoft.com>; Thu, 12 Dec 2002 19:59:57 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 477037 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 12 Dec 2002 19:59:57 -0500 Received: from 209.119.0.100 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 12 Dec 2002 19:49:57 -0500 Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00831569@cherry.ease.lsoft.com>; Thu, 12 Dec 2002 19:49:57 -0500 Message-ID: Date: Thu, 12 Dec 2002 19:49:56 -0500 Reply-To: Mailing List Sender: Mailing List From: Mukund Jagannathan Subject: ospfNbrAddressLessIndex To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list 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 Thu Dec 12 23:04:42 2002 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 XAA27989 for ; Thu, 12 Dec 2002 23:04:41 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00831C8A@cherry.ease.lsoft.com>; Thu, 12 Dec 2002 23:07:36 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 477350 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 12 Dec 2002 23:07:36 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 12 Dec 2002 23:07:36 -0500 Received: from redback.com (login003.redback.com [155.53.12.55]) by prattle.redback.com (Postfix) with ESMTP id DBE361E9015 for ; Thu, 12 Dec 2002 20:07:34 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; 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 Message-ID: <3DF95DFB.8030804@redback.com> Date: Thu, 12 Dec 2002 23:11:39 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: ospfNbrAddressLessIndex To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Mukund, My take is that this value is to provide a unique index when there are parallel unnumbered links between two routers. Therefore, it corresponds to the local unnumbered interface's ifIndex. 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 > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Fri Dec 13 01:54:42 2002 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 BAA06858 for ; Fri, 13 Dec 2002 01:54:42 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.00832064@cherry.ease.lsoft.com>; Fri, 13 Dec 2002 1:57:35 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 477737 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 13 Dec 2002 01:57:34 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 13 Dec 2002 01:57:34 -0500 Received: from redback.com (login003.redback.com [155.53.12.55]) by prattle.redback.com (Postfix) with ESMTP id 1F571F2C4F for ; Thu, 12 Dec 2002 22:55:39 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; 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 Message-ID: <3DF9855E.7080902@redback.com> Date: Fri, 13 Dec 2002 01:59:42 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: OSPF Link state request list management question To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi Dan, Vishwas is correct. See additional clarification and references to applicable sections in RFC 2328. The fact that a given implementation drops the adjacency is probably due to the relative scheduling priorities for LS update processing versus flooding (or possibly flooding is dampened). Thanks, Acee Manral, Vishwas wrote: > Hi Dan, > > I am a bit confused about the scenario you have given, however let me try to > explain the behavior as given in the RFC(I think I got ur scenario right), I > am not sure about the Cisco implementation though. > > 1. Router B has an LSA x in the Link-State Request list on neighbors A and > C. > > 2. Now B gets the LSA from C. When this happens it removes the LSA from the > request list of A(I think you miss this step). Precisely, B determines it is a newer LSA and floods it out some subset of its interfaces (Section 13, step 5, (b)). (b) Otherwise immediately flood the new LSA out some subset of the router's interfaces (see Section 13.3). In some cases (e.g., the state of the receiving interface is DR and the LSA was received from a router other than the Backup DR) the LSA will be flooded back out the receiving interface. This occurrence should be noted for later use by the acknowledgment process (Section 13.5). Then in section 13.3, the LSA is removed from router B's neighbor link state request list for router A. (b) Else, if the adjacency is not yet full (neighbor state is Exchange or Loading), examine the Link state request list associated with this adjacency. If there is an instance of the new LSA on the list, it indicates that the neighboring router has an instance of the LSA already. Compare the new LSA to the neighbor's copy: o If the new LSA is less recent, then examine the next neighbor. o If the two copies are the same instance, then delete the LSA from the Link state request list, and examine the next neighbor.[20] o Else, the new LSA is more recent. Delete the LSA from the Link state request list. > > 3. Now we get the same LSA from A, the link state request list of A however > does not contain this LSA, as it has been removed in step 2. > > 4. Hence we do not meet condition in step 6(of the RFC), and go to step 7, > and perform the steps needed when the same instance is got. > > Regarding why in step 6 we restart DB exchange, I think it is because the > step does not occur in a valid condition, so if the condition is met > something is wrong with the DB exchange and hence the DB exchange is > restarted for precuation sake. > > Regarding the an implementation which goes wrong in the above scenario, I > think it is probably a timing issue, where the LSA has been updated in the > LSDB but not removed from the request list, and the processing of the new > LSA is begun in the timeframe. > > Please let me know if I have addressed ur concerns. > > Thanks, > Vishwas > > -----Original Message----- > From: Dovolsky, Dan [mailto:ddovolsky@MOVAZ.COM] > Sent: Wednesday, December 11, 2002 5:30 AM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: OSPF Link state request list management question > > > BSD. > > > I will be appreciated to anyone who can help me with following question: > > Suppose we have some triangle network topology (routers A,B and C) where > each router has two adjacencies. > > Router A has rebooted. After restart, it attempts to reestablish > adjacency with routers B and C. After exchange DB descriptors, Router B > decided, > that it has to request some missing LSA from router A and send request to > it. > > Immediately after that, router B received this missing LSA from router C > (adjacency between A and C comes first). When the requested LSA received > from router A, > adjacency between B and A is restarted. > > This behavior proved to be real on Cisco router, and it actually defined by > spec: > > OSPF RFC2328, section 13. The Flooding Procedure states: > > "(6) Else, if there is an instance of the LSA on the sending > neighbor's Link state request list, an error has occurred in the > Database Exchange process. In this case, restart the Database > Exchange process by generating the neighbor event BadLSReq for > the sending neighbor and stop processing the Link State Update > packet." > > However, in section 13.3. Next step in the flooding procedure: > > "Also included in this part of the flooding procedure is the > maintenance of the neighbors' Link state request lists. > .... > (b) Else, if the adjacency is not yet full (neighbor state > is Exchange or Loading), examine the Link state request > list associated with this adjacency. If there is an > instance of the new LSA on the list, it indicates that > the neighboring router has an instance of the LSA > already. Compare the new LSA to the neighbor's copy: > > o If the new LSA is less recent, then examine the next > neighbor. > > o If the two copies are the same instance, then delete > the LSA from the Link state request list, and > examine the next neighbor.[20] > > o Else, the new LSA is more recent. Delete the LSA > from the Link state request list. > > (c) If the new LSA was received from this neighbor, examine > the next neighbor." > > > My question is why OSPF needs that section 13 (6) part and require > unnecessary adjacency restarting ? > > Following to this section 6 text (sections 7 and 8) define this case > processing very well: > > "(7) Else, if the received LSA is the same instance as the database > copy (i.e., neither one is more recent) the following two steps > should be performed: > > (a) If the LSA is listed in the Link state retransmission list > for the receiving adjacency, the router itself is expecting > an acknowledgment for this LSA. The router should treat the > received LSA as an acknowledgment by removing the LSA from > the Link state retransmission list. This is termed an > "implied acknowledgment". Its occurrence should be noted > for later use by the acknowledgment process (Section 13.5). > > (b) Possibly acknowledge the receipt of the LSA by sending a > Link State Acknowledgment packet back out the receiving > interface. This is explained below in Section 13.5. > > (8) Else, the database copy is more recent. If the database copy > has LS age equal to MaxAge and LS sequence number equal to > MaxSequenceNumber, simply discard the received LSA without > acknowledging it. (In this case, the LSA's LS sequence number is > wrapping, and the MaxSequenceNumber LSA must be completely > flushed before any new LSA instance can be introduced). > Otherwise, as long as the database copy has not been sent in a > Link State Update within the last MinLSArrival seconds, send the > database copy back to the sending neighbor, encapsulated within > a Link State Update Packet. The Link State Update Packet should > be sent directly to the neighbor..." > > Regards, > Dan Dovolsky. > > Office: 703-847-2438 > ddovolsky@movaz.com > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Fri Dec 13 01:58:48 2002 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 BAA06896 for ; Fri, 13 Dec 2002 01:58:48 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00832017@cherry.ease.lsoft.com>; Fri, 13 Dec 2002 2:01:42 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 477771 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 13 Dec 2002 02:01:41 -0500 Received: from 216.136.173.32 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 13 Dec 2002 02:01:41 -0500 Received: from 12-234-140-126.client.attbi.com (HELO suresh) (srisuresh@12.234.140.126 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 13 Dec 2002 06:17:04 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Message-ID: Date: Thu, 12 Dec 2002 22:20:52 -0800 Reply-To: Mailing List Sender: Mailing List From: Pyda Srisuresh Subject: Re: draft-srisuresh-ospf-te-04.txt Comments: To: Rohit Dube Comments: cc: pjoseph@Force10Networks.com, zinin@psg.com, fenner@research.att.com To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <200212121600.LAA22016@bigbird.xebeo.com> Precedence: list Content-Transfer-Encoding: 7bit My comments below. regards, suresh -----Original Message----- From: Rohit Dube [mailto:rohit@xebeo.com] Sent: Thursday, December 12, 2002 8:01 AM To: srisuresh@yahoo.com Cc: pjoseph@Force10Networks.com; zinin@psg.com; fenner@research.att.com; ospf@discuss.microsoft.com Subject: Re: draft-srisuresh-ospf-te-04.txt Hello, Some comments inline. On Thu, 12 Dec 2002 07:39:52 -0800 "Pyda Srisuresh" writes: =>Rohit, => =>I am taking te-wg off the mail list as the following =>discussion pertains to OSPF WG only. => =>I was not present at the Atlanta IETF. But, I looked =>at the work group minutes posted on 12/11. The minutes =>say that MOSPF and OSPF-flooding reduction are beign dropped =>from the charter. I saw no mention of alternate ospf-te =>proposals from being dropped. This is correct. I should have been more precise in what I said - I was trying to convey that we have a broadly agreed upon charter. While the charter was being discussed on the list or at WG meeting in Atlanta there was no voiced-concern about not including alternate ospf-te proposals in the charter. [SURESH] Thank you for the clarification. Typically, when a WG revises its charter (or) when a new WG is formed, for that matter, a mission statement is created describing its charter. That is followed by a list of Goals/Milestones. The items under the Goals section will naturally have fallen under the WG charter mission statement. I was looking for the revised OSPF WG mission statement to bring up the relevance of the OSPF-TE draft to the WG. I couldnt guess you were going about the other way around (i.e., going from the Goals/milestones and dropped list to imply a misson statement). A charter is incomplete without a mission statement; and is bound to be problematic for every new draft that finds its way. I suggest, you prepare a mission statement for the WG before the charter is finalized. As Acee and I explained at the Atlanta meeting, before picking up new charter items, we would like to see interest (and public comment) from deployers. Could you point to such interest in the alternate draft - since an alternate ospf-te proposal would have to be a new charter item at this point. [SURESH] Rohit - As you know, implementation, deployment and interoperability are not a requirement for a proposed standard. I.e., this line of argument should not be a gating item for a draft to become a proposed standard. I am sure, the ADs will attest to that. Having said that, we do have at least one implementation and verfication of portions of the OSPF-TE in an MPLS packet network. Spepcifically, the following are implemented and verified in a network consisting of OSPF-TE and native OSPF routers. a) The Hello protocol(Detection of TE-neighbor) and the selective flooding as a result. b) TE-router LSA, c) TE-incremental-link-update LSA, and the Sequence number generation. TE-router LSA when updated after 30 minutes assumes a sequence number larger than the last updated link. d) TE-LSDB generation; No hindrance to native OSPF protocol and the native LSDB. > 3. Following => =>Same thing goes for the mailing list. I am not aware of any =>discussion on the list suggesting alternate ospf-te proposals =>being dropped from the charter. Correct again. Hope my comment above clarifies what I meant. [SURESH] OK. I will repeat the request - Please provide a revised charter statement for the WG. I get the impression that there is too much to handle for this WG as it is - with V2 bug fixes, BCPs, V3 etc. This in turn is impacting what gets done for newer items such as TE extensions to the OSPF. Several important items are falling off the radar list. My recommendation would be to form a new OSPF-TE work group to focus exclusively on the TE extensions to OSPF. => =>If the WG charter is to cover the OSPF for TE and non-TE, the =>charter must include discussion of multiple ospf-te proposals. =>If the charter is written to imply that it covers Opaque LSA =>based TE extensions only and no alternate ospf-te proposals, then =>such an implication is not apparent and should be discussed. =>katz-yeung draft has several shortcomings, hasnt completed the =>IETF last call and is not an RFC yet. To presuppose the =>katz-yeung draft to be the only viable TE protocol and to =>exclude alternate proposals is a mistake, IMHO. You are welcome to argue this out on the mailing list. In its favour, katz-yeung has multiple (probably > 10 by now) implementations many of which are known to inter-operate and are deployed in live networks. While I would agree with you that there are shortcomings in katz-yeung, any competing draft has to be more than a little bit better to overcome the experience implementors and deployers have obtained with this solution. [SURESH] Rohit - Why do you say that the OSPF-TE is a little bit better than the katz-yeung draft? There is hardly anything in common between the two drafts. Perhaps, the only thing in common is that TE link metrics are represented as TLVs in both drafts. However, the TLV usage is different between the two drafts. The OSPF-TE design is driven by different motivations and is based on a different paradigm than the katz-yeung draft. The katz-yeung draft is simply not as comprehensive as the OSPF-TE draft. I would urge you to review the OSPF-TE draft and send us your thoughts and comments on specific items. => =>Would appreciate your posting the exact wording of the updated =>charter for the WG on the mailing list. Attached below. I have requested the ADs to post this on the ospf-wg web page so that it is easier to access. => =>regards, =>suresh => Best, --rohit. regards, suresh From owner-ospf@DISCUSS.MICROSOFT.COM Fri Dec 13 10:49:53 2002 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 KAA26588 for ; Fri, 13 Dec 2002 10:49:53 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.0083298A@cherry.ease.lsoft.com>; Fri, 13 Dec 2002 10:52:48 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 479493 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 13 Dec 2002 10:52:48 -0500 Received: from 204.192.44.242 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 13 Dec 2002 10:52:48 -0500 Received: (qmail 21031 invoked from network); 13 Dec 2002 15:52:47 -0000 Received: from bigbird.xebeo.com (192.168.0.21) by lxmail.xebeo.com with SMTP; 13 Dec 2002 15:52:47 -0000 Received: from bigbird.xebeo.com (localhost.localdomain [127.0.0.1]) by bigbird.xebeo.com (8.9.3/8.9.3) with ESMTP id KAA29294; Fri, 13 Dec 2002 10:52:46 -0500 X-Mailer: exmh version 2.1.1 10/15/1999 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <200212131552.KAA29294@bigbird.xebeo.com> Date: Fri, 13 Dec 2002 10:52:46 -0500 Reply-To: Mailing List Sender: Mailing List From: Rohit Dube Subject: Re: draft-srisuresh-ospf-te-04.txt Comments: To: srisuresh@yahoo.com Comments: cc: pjoseph@Force10Networks.com, zinin@psg.com, fenner@research.att.com To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Message from "Pyda Srisuresh" of "Thu, 12 Dec 2002 22:20:52 PST." Precedence: list [..] =>[SURESH] Thank you for the clarification. => => Typically, when a WG revises its charter (or) when a new => WG is formed, for that matter, a mission statement => is created describing its charter. That is followed by => a list of Goals/Milestones. The items under the Goals => section will naturally have fallen under the WG charter => mission statement. => => I was looking for the revised OSPF WG mission statement => to bring up the relevance of the OSPF-TE draft to the WG. => I couldnt guess you were going about the other way around => (i.e., going from the Goals/milestones and dropped list => to imply a misson statement). => => A charter is incomplete without a mission statement; and is => bound to be problematic for every new draft that finds its => way. I suggest, you prepare a mission statement for the WG => before the charter is finalized. The mission of the current charter (as has been explained multiple times) is to clear of existing items of the table. I don't believe anything grander is in order at this time. => =>[SURESH] Rohit - As you know, implementation, deployment and => interoperability are not a requirement for a proposed => standard. I.e., this line of argument should not be a => gating item for a draft to become a proposed standard. [snip] Sure this is well known. But pragmatism dictates that there is no point in pursuing something which is either "only a little bit better than an existing solution" or "has little interest or support" or both. =>[SURESH] OK. I will repeat the request - Please provide a revised => charter statement for the WG. I believe I have done as best as I could above and in previous mails on the topic of the charter. => => I get the impression that there is too much to handle => for this WG as it is - with V2 bug fixes, BCPs, V3 etc. => This in turn is impacting what gets done for newer => items such as TE extensions to the OSPF. Several => important items are falling off the radar list. => => My recommendation would be to form a new OSPF-TE work => group to focus exclusively on the TE extensions to OSPF. [snip] You are welcome to take this to the Routing-Area ADs since it is neither in my power or (in my opinion) in the ospf-wg's interest to do such a thing. Summary: There is insufficient interest to proceed any further with the alternate ospf-te proposal in the ospf wg. [If anybody other than the authors disagree with this please post to the list indicating why you think an alternate ospf-te proposal is needed.] --rohit. From owner-ospf@DISCUSS.MICROSOFT.COM Fri Dec 13 11:36:08 2002 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 LAA27565 for ; Fri, 13 Dec 2002 11:36:07 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.00832AE9@cherry.ease.lsoft.com>; Fri, 13 Dec 2002 11:39:03 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 479624 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 13 Dec 2002 11:39:03 -0500 Received: from 63.165.80.17 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 13 Dec 2002 11:39:03 -0500 Received: by apollo.adtech-inc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 13 Dec 2002 06:39:34 -1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <8AC36D3167EED41184C800508BD954050320B8AE@apollo.adtech-inc.com> Date: Fri, 13 Dec 2002 06:39:33 -1000 Reply-To: Mailing List Sender: Mailing List From: "Singh, Gurpreet" Subject: NSSA, Opaque-LSA, Demand Circuits, Database Overflow drafts/RFC for IPv6 ? To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Just had a query reagrding the draft/RFC for NSSA, Opaque-LSA, Demand Circuits, Database Overflow drafts/RFC for IPv6. Is something planned for this in the future or the operation of these OSPF extenstions will be same as defined in the drafts/RFCs for IPv4 ? Gurpreet From owner-ospf@DISCUSS.MICROSOFT.COM Fri Dec 13 11:50:59 2002 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 LAA28078 for ; Fri, 13 Dec 2002 11:50:59 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.00832A7F@cherry.ease.lsoft.com>; Fri, 13 Dec 2002 11:53:55 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 479685 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 13 Dec 2002 11:53:55 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 13 Dec 2002 11:53:55 -0500 Received: from redback.com (login003.redback.com [155.53.12.55]) by prattle.redback.com (Postfix) with ESMTP id D6159262808 for ; Fri, 13 Dec 2002 08:53:53 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <8AC36D3167EED41184C800508BD954050320B8AE@apollo.adtech-inc.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3DFA118F.20703@redback.com> Date: Fri, 13 Dec 2002 11:57:51 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: NSSA, Opaque-LSA, Demand Circuits, Database Overflow drafts/RFC for IPv6 ? To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Gurpreet, Here are my opinions: Demand Circuit - IPv6 Version not necessary (DC bit is in LSA Options) Database Overflow - Not really necessary - just apply the behavior to the LSAs with external flooding scope NSSA - Debatable - Probably could stand a short note since RFC 2740 doesn't cover it explicitly. Opaque LSA - Area of discussion whether or not these are needed Singh, Gurpreet wrote: > Hi > > Just had a query reagrding the draft/RFC for NSSA, Opaque-LSA, Demand > Circuits, Database Overflow drafts/RFC for IPv6. Is something planned for > this in the future or the operation of these OSPF extenstions will be same > as defined in the drafts/RFCs for IPv4 ? > > Gurpreet > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Fri Dec 13 12:15:05 2002 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 MAA28696 for ; Fri, 13 Dec 2002 12:15:05 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00832AB9@cherry.ease.lsoft.com>; Fri, 13 Dec 2002 12:17:59 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 479835 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 13 Dec 2002 12:17:59 -0500 Received: from 203.199.83.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 13 Dec 2002 12:17:47 -0500 Received: (qmail 836 invoked by uid 510); 13 Dec 2002 17:17:14 -0000 Received: from unknown (203.197.138.194) by rediffmail.com via HTTP; 13 dec 2002 17:17:14 -0000 MIME-Version: 1.0 Content-type: text/plain; format=flowed Content-Disposition: inline Message-ID: <20021213171714.835.qmail@webmail26.rediffmail.com> Date: Fri, 13 Dec 2002 17:17:14 -0000 Reply-To: Mailing List Sender: Mailing List From: Rajesh G Subject: Re: Router link origination when interface is up To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Thanks Acee, but I am not able to appreciate the need of advertising a network as stub and let all other routers flood that info and then after a small period again advertise the network as transit. what exactly are we gaining by advertising immediately when the interface is up instead of delaying till we come out of the waiting state? On Thu, 12 Dec 2002 Acee Lindem wrote : >Rajesh G wrote: >>Hi, >> >> When ospf is enabled on an interface in which we >>already >>have valid DR and BDR for the network, we face the following >>problem. As soon as the interface comes up a router LSA is >>generated stating the network as stub (as we don't have >>knowledge >>about other routers in the n/w). After some time we get a >>hello >>packet from a neighbor giving us the DR and BDR for the n/w >>which >>we accept. Here we do not re-build our own router LSA. Even if >>we >>run the DR election and dont find any change in the DR status, >>we >>still don't rebuild our router LSA. So we advertise the n/w as >>stub link, till the refresh interval. >> >> What could be the possible solution to avoid this >>problem. >>My guess is that we should not originate our router LSA till >>we >>are sure about the nature of the network (either our wait >>timer >>expires or we get a Hello with a valid DR and BDR on the n/w). >>Is >>this correct? please give your inputs. > >Rajesh - don't delay origination. You should re-originate your >router LSA when you go to FULL state with the DR. Look at >section >12.4 in RFC 2328. > >> >>TIA, >> >>Rajesh >> > > >-- >Acee From owner-ospf@DISCUSS.MICROSOFT.COM Fri Dec 13 12:24:40 2002 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 MAA28963 for ; Fri, 13 Dec 2002 12:24:40 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00832C0D@cherry.ease.lsoft.com>; Fri, 13 Dec 2002 12:27:36 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 479863 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 13 Dec 2002 12:27:36 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 13 Dec 2002 12:27:36 -0500 Received: from redback.com (login003.redback.com [155.53.12.55]) by prattle.redback.com (Postfix) with ESMTP id 2E0EB1EB850 for ; Fri, 13 Dec 2002 09:27:35 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <20021213171714.835.qmail@webmail26.rediffmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3DFA1974.3090102@redback.com> Date: Fri, 13 Dec 2002 12:31:32 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Router link origination when interface is up To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Rajesh G wrote: > Thanks Acee, but I am not able to appreciate the need > of advertising a network as stub and let all other routers > flood that info and then after a small period again advertise > the network as transit. > what exactly are we gaining by advertising immediately when > the interface is up instead of delaying till we come out of the > waiting state? The wait interval (in terms of connectivity) is not a small period. It is better just to re-originate your router LSA as changes occur and only delay MinLSInterval seconds between sucessive originations of the same LSA. > > > On Thu, 12 Dec 2002 Acee Lindem wrote : > >> Rajesh G wrote: >> >>> Hi, >>> >>> When ospf is enabled on an interface in which we >>> already >>> have valid DR and BDR for the network, we face the following >>> problem. As soon as the interface comes up a router LSA is >>> generated stating the network as stub (as we don't have >>> knowledge >>> about other routers in the n/w). After some time we get a >>> hello >>> packet from a neighbor giving us the DR and BDR for the n/w >>> which >>> we accept. Here we do not re-build our own router LSA. Even if >>> we >>> run the DR election and dont find any change in the DR status, >>> we >>> still don't rebuild our router LSA. So we advertise the n/w as >>> stub link, till the refresh interval. >>> >>> What could be the possible solution to avoid this >>> problem. >>> My guess is that we should not originate our router LSA till >>> we >>> are sure about the nature of the network (either our wait >>> timer >>> expires or we get a Hello with a valid DR and BDR on the n/w). >>> Is >>> this correct? please give your inputs. >> >> >> Rajesh - don't delay origination. You should re-originate your >> router LSA when you go to FULL state with the DR. Look at >> section >> 12.4 in RFC 2328. >> >>> >>> TIA, >>> >>> Rajesh >>> >> >> >> -- >> Acee > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Fri Dec 13 12:51:34 2002 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 MAA29765 for ; Fri, 13 Dec 2002 12:51:33 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.00832C54@cherry.ease.lsoft.com>; Fri, 13 Dec 2002 12:54:29 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 479954 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 13 Dec 2002 12:54:29 -0500 Received: from 147.28.0.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 13 Dec 2002 12:54:29 -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 18Mu16-000AWt-00; Fri, 13 Dec 2002 09:54:28 -0800 X-Mailer: The Bat! (v1.51) Personal X-Priority: 3 (Normal) References: <200212122223.gBCMNSZ27071@kummer.juniper.net> <3DF90F69.7030107@redback.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3691769647.20021213095358@psg.com> Date: Fri, 13 Dec 2002 09:53:58 -0800 Reply-To: Mailing List Sender: Mailing List From: Alex Zinin Subject: Re: Updated WG Minutes Comments: To: Acee Lindem To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3DF90F69.7030107@redback.com> Precedence: list Content-Transfer-Encoding: 7bit Acee, I sent you mine unicast yesterday. Let me know if you'd like me to repost them to the list, pls. -- Alex Thursday, December 12, 2002, 2:36:25 PM, Acee Lindem wrote: > Anybody else???? I should have know that if I sent them in I'd > get some additional comments. > Thanks, > Acee From owner-ospf@DISCUSS.MICROSOFT.COM Fri Dec 13 14:36:28 2002 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 OAA03186 for ; Fri, 13 Dec 2002 14:36:28 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.00832D99@cherry.ease.lsoft.com>; Fri, 13 Dec 2002 14:39:22 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 480270 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 13 Dec 2002 14:39:22 -0500 Received: from 209.119.0.100 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 13 Dec 2002 14:39:22 -0500 Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.00832E78@cherry.ease.lsoft.com>; Fri, 13 Dec 2002 14:39:22 -0500 Message-ID: Date: Fri, 13 Dec 2002 14:39:22 -0500 Reply-To: Mailing List Sender: Mailing List From: Hatem Eyada Subject: Win2k Server Support For Ospfv3 & IPv6. To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi All, Does any one know whether Win2k server supports Ospfv3 or not? If yes, please tell me where I can find info. about configuring Win2k server as Ospfv3 router. Also I know that Win2k supports IPv6 but I don't know what dos/windows commands I can use to configure IPv6 (i.e. Adding IPv6 address to an interface, adding IPv6 route to the routing table, etc...). For IPv4 I use the command "route" to manipulate the routing table, is there an equivalent command for IPv6? Thanks in advance for your help. Thanks, Hatem From owner-ospf@DISCUSS.MICROSOFT.COM Fri Dec 13 16:17:56 2002 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 QAA05545 for ; Fri, 13 Dec 2002 16:17:56 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.008330C4@cherry.ease.lsoft.com>; Fri, 13 Dec 2002 16:20:51 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 480589 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 13 Dec 2002 16:20:51 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 13 Dec 2002 16:20:51 -0500 Received: from redback.com (login003.redback.com [155.53.12.55]) by prattle.redback.com (Postfix) with ESMTP id ABF871EB9AB for ; Fri, 13 Dec 2002 13:20:49 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 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: <3DFA501D.5010304@redback.com> Date: Fri, 13 Dec 2002 16:24:45 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Extensions to IS-IS and OSPF for Advertising Optional Capabilities To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit This draft was presented at the 55th IETF OSPF WG. At the meeting, it was concluded that more discussion was needed prior to deciding whether or not to accept it as a WG document (and we're currently trying to finish up at least some items on the charter before accepting new items). At this time, I'd like to initiate that discussion. [Speaking as WG member] As one of the draft authors, I believe the draft is the natural way to overcome the limitation that we have exhausted the available OSPFv2 LSA options bits. While we can't require existing OSPF features to use this mechanism, it can be very useful for advertising support of new features. OSPF PCS (Path Computation Server) discovery will be the first of the new features using the mechanism. [End Speaking as WG member] http://www.ietf.org/internet-drafts/draft-raggarwa-igp-cap-01.txt -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Wed Dec 18 10:52:01 2002 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 KAA11393 for ; Wed, 18 Dec 2002 10:52:01 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.008429AE@cherry.ease.lsoft.com>; Wed, 18 Dec 2002 10:55:00 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 491809 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 18 Dec 2002 10:55:00 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 18 Dec 2002 10:55:00 -0500 Received: from redback.com (login002.redback.com [155.53.12.54]) by prattle.redback.com (Postfix) with ESMTP id DDD40842E5; Wed, 18 Dec 2002 07:54:52 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 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: <3E009AFA.9010208@redback.com> Date: Wed, 18 Dec 2002 10:57:46 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: OSPFv3 Applications Support Comments: cc: Kireeti Kompella , Kunihiro Ishiguro To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit 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. I'll defer any opinions of my own to separate E-mail speaking as a WG member. In any case, we need to reach a rough concensus on this as it will impact future work. -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Wed Dec 18 14:25:32 2002 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 OAA16505 for ; Wed, 18 Dec 2002 14:25:31 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00843030@cherry.ease.lsoft.com>; Wed, 18 Dec 2002 14:28:30 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 492274 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 18 Dec 2002 14:28:29 -0500 Received: from 209.119.0.100 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 18 Dec 2002 14:18:29 -0500 Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00842E87@cherry.ease.lsoft.com>; Wed, 18 Dec 2002 14:18:29 -0500 Message-ID: Date: Wed, 18 Dec 2002 14:18:28 -0500 Reply-To: Mailing List Sender: Mailing List From: Igor Miroshnik Subject: Originating Summary LSAs To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi, Should an ASBR be advertised into an area which has its own intra-area route to that ASBR? Does the answer differ if the router supports only RFC1583? For my understanding of RFC1583, RFC2178, and RFC2328, it should be advertised. Am I mistaking? Thanks, Igor From owner-ospf@DISCUSS.MICROSOFT.COM Wed Dec 18 18:32:28 2002 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 SAA21955 for ; Wed, 18 Dec 2002 18:32:27 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.00843C47@cherry.ease.lsoft.com>; Wed, 18 Dec 2002 18:35:26 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 475639 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 18 Dec 2002 18:35:25 -0500 Received: from 144.254.74.60 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 18 Dec 2002 18:25:25 -0500 Received: from cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBINO0rR027903; Thu, 19 Dec 2002 00:24:01 +0100 (MET) Received: from JVASSEUR-W2K.cisco.com (sjc-vpn2-493.cisco.com [10.21.113.237]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id AAA11580; Thu, 19 Dec 2002 00:25:22 +0100 (MET) X-Sender: jvasseur@paris.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_631448114==_.ALT" Message-ID: <4.3.2.7.2.20021218182458.048005f8@paris.cisco.com> Date: Wed, 18 Dec 2002 18:25:21 -0500 Reply-To: Mailing List Sender: Mailing List From: Jean Philippe Vasseur Subject: Fwd: Re: Extensions to IS-IS and OSPF for Advertising Optional Capabilities Comments: cc: acee Lindem To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list --=====================_631448114==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Acee, >Date: Wed, 18 Dec 2002 18:09:58 -0500 >To: OSPF@DISCUSS.MICROSOFT.COM >From: Jean Philippe Vasseur >Subject: Fwd: Re: Extensions to IS-IS and OSPF for Advertising Optional >Capabilities >Cc: Acee Lindem > > >>Date: Fri, 13 Dec 2002 18:17:22 -0500 >>To: Mailing List >>From: Jean Philippe Vasseur >>Subject: Re: Extensions to IS-IS and OSPF for Advertising Optional >>Capabilities >>Cc: OSPF@DISCUSS.MICROSOFT.COM >> >>Hi Acee, >> >>At 16:24 13/12/2002 -0500, Acee Lindem wrote: >>>This draft was presented at the 55th IETF OSPF WG. At the meeting, >>>it was concluded that more discussion was needed prior to deciding >>>whether or not to accept it as a WG document (and we're currently >>>trying to finish up at least some items on the charter before accepting >>>new items). At this time, I'd like to initiate that discussion. >>> >>>[Speaking as WG member] >>> >>>As one of the draft authors, I believe the draft is the natural way to >>>overcome the limitation that we have exhausted the available OSPFv2 >>>LSA options bits. While we can't require existing OSPF features to >>>use this mechanism, it can be very useful for advertising support >>>of new features. OSPF PCS (Path Computation Server) discovery will be >>>the first of the new features using the mechanism. >> >>I'd like to mention two other applications making use of this draft: >> >>1) Auto-mesh TE. >> >>The related TLV carried within the OSFP router information LSA defined in >>draft-raggarwa-igp-cap-01.txt is described in >>http://www.ietf.org/internet-drafts/draft-vasseur-mpls-ospf-te-cap-00.txt >> >>3.2 Mesh-group TLV >> >> As of today, there are different approaches in deploying MPLS >> Traffic Engineering: >> (1) the systematic approach consisting of setting up a full >> mesh of tunnels between P or PE routers, with the objective of >> optimizing the bandwidth usage in the core, >> (2) the "by exception" approach where a set TE LSPs are set up >> on hot spots to alleviate a congestion resulting in an >> unexpected traffic growth in some part of the network. >> >> The systematic approach requires setting up a full mesh of TE LSPs, >> which implies the configuration of a large number of tunnels on >> every Hean-End LSR (P or PE LSR). A full TE mesh of n LSRs requires >> the set up of O(n^2) TE LSPs. Furthermore, the addition of any new >> LSR in the mesh implies to configure n TE LSPs on the new LSR and to >> add a new TE LSP on every LSR ending to this new LSR, which gives a >> total of 2*n TE LSPs. This is not only time consuming but also not a >> low risk operation for Service Providers. So a more automatic way of >> setting up full mesh of TE LSP might be desirable. This requires to >> define a new TE capability TLV (called the Mesh-group TLV) such that >> an LSR can announce its desire to join a particular TE LSP mesh, >> identified by a mesh-group number. >> >>I'll publish an informational draft soon detailing some possible >>deployment scenarios. >> >>2) It might also be useful to announce some NSF node property. This will >>be detailed in another draft. >> >>Those two applications, in addition to the Path computation Server >>discovery mentioned above, make use of draft-raggarwa-igp-cap-01.txt >> >>JP. >> >>>[End Speaking as WG member] >>> >>> >>>http://www.ietf.org/internet-drafts/draft-raggarwa-igp-cap-01.txt >>>-- >>>Acee --=====================_631448114==_.ALT Content-Type: text/html; charset="us-ascii" Hi Acee,

Date: Wed, 18 Dec 2002 18:09:58 -0500
To: OSPF@DISCUSS.MICROSOFT.COM
From: Jean Philippe Vasseur <jvasseur@cisco.com>
Subject: Fwd: Re: Extensions to IS-IS and OSPF for Advertising Optional Capabilities
Cc: Acee Lindem <acee@redback.com>


Date: Fri, 13 Dec 2002 18:17:22 -0500
To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Jean Philippe Vasseur <jvasseur@cisco.com>
Subject: Re: Extensions to IS-IS and OSPF for Advertising Optional Capabilities
Cc: OSPF@DISCUSS.MICROSOFT.COM

Hi Acee,

At 16:24 13/12/2002 -0500, Acee Lindem wrote:
This draft was presented at the 55th IETF OSPF WG. At the meeting,
it was concluded that more discussion was needed prior to deciding
whether or not to accept it as a WG document (and we're currently
trying to finish up at least some items on the charter before accepting
new items). At this time, I'd like to initiate that discussion.

[Speaking as WG member]

As one of the draft authors, I believe the draft is the natural way to
overcome the limitation that we have exhausted the available OSPFv2
LSA options bits. While we can't require existing OSPF features to
use this mechanism, it can be very useful for advertising support
of new features. OSPF PCS (Path Computation Server) discovery will be
the first of the new features using the mechanism.

I'd like to mention two other applications making use of this draft:

1) Auto-mesh TE.

The related TLV carried within the OSFP router information LSA defined in draft-raggarwa-igp-cap-01.txt is described in http://www.ietf.org/internet-drafts/draft-vasseur-mpls-ospf-te-cap-00.txt

3.2 Mesh-group TLV
   
   As of today, there are different approaches in deploying MPLS
   Traffic Engineering:
        (1) the systematic approach consisting of setting up a full
        mesh of tunnels between P or PE routers, with the objective of
        optimizing the bandwidth usage in the core,
        (2) the "by exception" approach where a set TE LSPs are set up
        on hot spots to alleviate a congestion resulting in an
        unexpected traffic growth in some part of the network. 
   
   The systematic approach requires setting up a full mesh of TE LSPs,
   which implies the configuration of a large number of tunnels on
   every Hean-End LSR (P or PE LSR). A full TE mesh of n LSRs requires
   the set up of O(n^2) TE LSPs. Furthermore, the addition of any new
   LSR in the mesh implies to configure n TE LSPs on the new LSR and to
   add a new TE LSP on every LSR ending to this new LSR, which gives a
   total of 2*n TE LSPs. This is not only time consuming but also not a
   low risk operation for Service Providers. So a more automatic way of
   setting up full mesh of TE LSP might be desirable. This requires to
   define a new TE capability TLV (called the Mesh-group TLV) such that
   an LSR can announce its desire to join a particular TE LSP mesh,
   identified by a mesh-group number.

I'll publish an informational draft soon detailing some possible deployment scenarios.

2) It might also be useful to announce some NSF node property. This will be detailed in another draft.

Those two applications, in addition to the Path computation Server discovery mentioned above, make use of draft-raggarwa-igp-cap-01.txt

JP.

[End Speaking as WG member]


http://www.ietf.org/internet-drafts/draft-raggarwa-igp-cap-01.txt
--
Acee
--=====================_631448114==_.ALT-- From owner-ospf@DISCUSS.MICROSOFT.COM Fri Dec 20 11:54:56 2002 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 LAA01981 for ; Fri, 20 Dec 2002 11:54:56 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.00847C52@cherry.ease.lsoft.com>; Fri, 20 Dec 2002 11:57:55 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 481072 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 20 Dec 2002 11:57:55 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 20 Dec 2002 11:57:55 -0500 Received: from redback.com (login002.redback.com [155.53.12.54]) by prattle.redback.com (Postfix) with ESMTP id 14334842E3 for ; Fri, 20 Dec 2002 08:57:54 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; 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 Message-ID: <3E034CA4.708@redback.com> Date: Fri, 20 Dec 2002 12:00:20 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Originating Summary LSAs To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Igor Miroshnik wrote: > Hi, > > Should an ASBR be advertised into an area which has its own intra-area > route to that ASBR? Does the answer differ if the router supports only > RFC1583? For my understanding of RFC1583, RFC2178, and RFC2328, it should > be advertised. Am I mistaking? Igor, My interpretation of section 12.4.3 is that an OSPF router should generate a summary into areas other than the area containing the best path (even if an intra-area path exists to the router in other areas). o Else, if the destination of this route is an AS boundary router, a summary-LSA should be originated if and only if the routing table entry describes the preferred path to the AS boundary router (see Step 3 of Section 16.4). If so, a Type 4 summary-LSA is originated for the destination, with Link State ID equal to the AS boundary router's Router ID and metric equal to the routing table entry's cost. Note: these LSAs should not be generated if Area A has been configured as a stub area. The determination of the best path to an ASBR changed from RFC 1583 to RFC 2178. I'd be interested if there are implementations that suppress the type 4 summary for areas having any intra-area path. Thanks, Acee > > Thanks, > Igor > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Fri Dec 20 23:48:53 2002 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 XAA20982 for ; Fri, 20 Dec 2002 23:48:52 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.0084957F@cherry.ease.lsoft.com>; Fri, 20 Dec 2002 23:51:53 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 483044 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 20 Dec 2002 23:51:52 -0500 Received: from 133.205.30.122 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 20 Dec 2002 23:51:52 -0500 Received: from localhost.localdomain (vprmatrix [127.0.0.1]) by localhost.localdomain (8.12.5/8.12.5) with ESMTP id gBL4pr47001601; Fri, 20 Dec 2002 20:51:53 -0800 References: <3E009AFA.9010208@redback.com> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/21.2.92 (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: <87hed8vus6.wl@localhost.localdomain> Date: Fri, 20 Dec 2002 20:51:53 -0800 Reply-To: Mailing List Sender: Mailing List From: Kunihiro Ishiguro Subject: Re: OSPFv3 Applications Support Comments: cc: Acee Lindem , Kireeti Kompella To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3E009AFA.9010208@redback.com> Precedence: list >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. -- Kunihiro Ishiguro From owner-ospf@DISCUSS.MICROSOFT.COM Sat Dec 21 13:53:52 2002 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 NAA10292 for ; Sat, 21 Dec 2002 13:53:52 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.0084A6D4@cherry.ease.lsoft.com>; Sat, 21 Dec 2002 13:56:51 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 484464 for OSPF@DISCUSS.MICROSOFT.COM; Sat, 21 Dec 2002 13:56:51 -0500 Received: from 216.136.131.37 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Sat, 21 Dec 2002 13:46:51 -0500 Received: from [209.179.251.131] by web10901.mail.yahoo.com via HTTP; Sat, 21 Dec 2002 10:46:51 PST MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20021221184651.57543.qmail@web10901.mail.yahoo.com> Date: Sat, 21 Dec 2002 10:46:51 -0800 Reply-To: Mailing List Sender: Mailing List From: j j Subject: Question about nexthop calculation To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list hello folks, I am going through Zebra and Moy's source code for OSPFv2. The question I have is when calculating next hops for a router vertex that is directly connected to the root (i.e. calculating router) via a network vertex, why can't we simply inherit the nexthops of the network vertex ? Moy and Zebra both do something special for this case which I cannot understand. It seems like the root should be able to reach the router through all the nexthops that were calculated for the network vertex. I hope I was able to clearly explain my doubts. thanks jasmine __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com From owner-ospf@DISCUSS.MICROSOFT.COM Sat Dec 21 14:24:21 2002 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 OAA10638 for ; Sat, 21 Dec 2002 14:24:21 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.0084A72F@cherry.ease.lsoft.com>; Sat, 21 Dec 2002 14:27:21 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 484513 for OSPF@DISCUSS.MICROSOFT.COM; Sat, 21 Dec 2002 14:27:21 -0500 Received: from 209.119.0.100 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Sat, 21 Dec 2002 14:27:21 -0500 Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.0084A6AB@cherry.ease.lsoft.com>; Sat, 21 Dec 2002 14:27:21 -0500 Message-ID: Date: Sat, 21 Dec 2002 14:27:21 -0500 Reply-To: Mailing List Sender: Mailing List From: Igor Miroshnik Subject: Re: Question about nexthop calculation To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list On Sat, 21 Dec 2002 10:46:51 -0800, j j wrote: >hello folks, > >I am going through Zebra and Moy's source code for >OSPFv2. The question I have is when calculating >next hops for a router vertex that is directly >connected to the root (i.e. calculating router) via >a network vertex, why can't we simply inherit the >nexthops of the network vertex ? Moy and Zebra both >do something special for this case which I cannot >understand. > >It seems like the root should be able to reach the >router through all the nexthops that were calculated >for the network vertex. > >I hope I was able to clearly explain my doubts. > >thanks > >jasmine Jasmine, The nexthop address for a router vertex via a network one is the IP address of the destination router on the network mentioned, whereas the nexthop address for a network vertex directly connected to the root is not. Actually, the latter does not have any nexthop. That is why we can't simply inherit the nexthops of that network vertex. In our implementation, that nexthop's address is zero. Thanks, Igor From owner-ospf@DISCUSS.MICROSOFT.COM Sat Dec 21 19:05:07 2002 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 TAA13692 for ; Sat, 21 Dec 2002 19:05:07 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.0084ACB6@cherry.ease.lsoft.com>; Sat, 21 Dec 2002 19:08:06 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 484904 for OSPF@DISCUSS.MICROSOFT.COM; Sat, 21 Dec 2002 19:08:06 -0500 Received: from 216.136.131.41 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Sat, 21 Dec 2002 19:08:06 -0500 Received: from [209.179.251.163] by web10905.mail.yahoo.com via HTTP; Sat, 21 Dec 2002 16:08:05 PST MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20021222000805.65949.qmail@web10905.mail.yahoo.com> Date: Sat, 21 Dec 2002 16:08:05 -0800 Reply-To: Mailing List Sender: Mailing List From: j j Subject: Re: Question about nexthop calculation To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Precedence: list Igor, Why is it necessary to record nexthops for routers connected via network to the root? Where is this information used? is it used to process stub links or inter-area route calcuations? thanks jasmine --- Igor Miroshnik wrote: > On Sat, 21 Dec 2002 10:46:51 -0800, j j > wrote: > > >hello folks, > > > >I am going through Zebra and Moy's source code for > >OSPFv2. The question I have is when calculating > >next hops for a router vertex that is directly > >connected to the root (i.e. calculating router) via > >a network vertex, why can't we simply inherit the > >nexthops of the network vertex ? Moy and Zebra both > >do something special for this case which I cannot > >understand. > > > >It seems like the root should be able to reach the > >router through all the nexthops that were > calculated > >for the network vertex. > > > >I hope I was able to clearly explain my doubts. > > > >thanks > > > >jasmine > > Jasmine, > > The nexthop address for a router vertex via a > network one is the IP address of the destination > router on the network mentioned, whereas the nexthop > address for a network vertex directly connected > to the root is not. Actually, the latter does not > have any nexthop. That is why we can't simply > inherit the nexthops of that network vertex. In our > implementation, that nexthop's address is zero. > > Thanks, > Igor __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com From owner-ospf@DISCUSS.MICROSOFT.COM Sat Dec 21 23:23:23 2002 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 XAA16263 for ; Sat, 21 Dec 2002 23:23:23 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.0084B17F@cherry.ease.lsoft.com>; Sat, 21 Dec 2002 23:26:24 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 485245 for OSPF@DISCUSS.MICROSOFT.COM; Sat, 21 Dec 2002 23:26:24 -0500 Received: from 209.119.0.100 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Sat, 21 Dec 2002 23:26:24 -0500 Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.0084B2EE@cherry.ease.lsoft.com>; Sat, 21 Dec 2002 23:26:24 -0500 Message-ID: Date: Sat, 21 Dec 2002 23:26:23 -0500 Reply-To: Mailing List Sender: Mailing List From: Igor Miroshnik Subject: Re: Question about nexthop calculation To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Jasmine, The information used immediately is the outgoing interface. Besides, at this stage the nexthop address can be retrieved from the link data of the directly connected router vertex. This nexthop address is used later, when a remote vertex inherits nexthops to the directly connected router vertices. Thanks, Igor --- j j wrote: >Igor, > >Why is it necessary to record nexthops for routers >connected via network to the root? Where is this >information used? >is it used to process stub links or inter-area >route calcuations? > >thanks > >jasmine > >--- Igor Miroshnik wrote: >> On Sat, 21 Dec 2002 10:46:51 -0800, j j >> wrote: >> >> >hello folks, >> > >> >I am going through Zebra and Moy's source code for >> >OSPFv2. The question I have is when calculating >> >next hops for a router vertex that is directly >> >connected to the root (i.e. calculating router) via >> >a network vertex, why can't we simply inherit the >> >nexthops of the network vertex ? Moy and Zebra both >> >do something special for this case which I cannot >> >understand. >> > >> >It seems like the root should be able to reach the >> >router through all the nexthops that were >> calculated >> >for the network vertex. >> > >> >I hope I was able to clearly explain my doubts. >> > >> >thanks >> > >> >jasmine >> >> Jasmine, >> >> The nexthop address for a router vertex via a >> network one is the IP address of the destination >> router on the network mentioned, whereas the nexthop >> address for a network vertex directly connected >> to the root is not. Actually, the latter does not >> have any nexthop. That is why we can't simply >> inherit the nexthops of that network vertex. In our >> implementation, that nexthop's address is zero. >> >> Thanks, >> Igor From owner-ospf@DISCUSS.MICROSOFT.COM Sun Dec 22 13:36:50 2002 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 NAA04190 for ; Sun, 22 Dec 2002 13:36:50 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.0084C11B@cherry.ease.lsoft.com>; 22 Dec 2002 13:39:50 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 487139 for OSPF@DISCUSS.MICROSOFT.COM; Sun, 22 Dec 2002 13:39:49 -0500 Received: from 216.136.131.37 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Sun, 22 Dec 2002 13:39:49 -0500 Received: from [209.179.217.147] by web10901.mail.yahoo.com via HTTP; Sun, 22 Dec 2002 10:39:49 PST MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20021222183949.74993.qmail@web10901.mail.yahoo.com> Date: Sun, 22 Dec 2002 10:39:49 -0800 Reply-To: Mailing List Sender: Mailing List From: j j Subject: nexthop calculations To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list But ultimately the nexthop records for router vertices get used to determine routes to stub networks being advertised by that particular router and during inter-area route calcuations. Because as I understand it router vertices are ignored as far as populating RIB goes. Only network vertices are considered. true? Second question to anybody who is familiar with zebra code. In ospf_nexthop_calculation(), for a directly connected (via point-to-point link) child router vertex, zebra does following : for each link L1 in parent's router lsa pointing to child { for each link L2 in child's router lsa pointing to parent { get interface associated with L2->link_data; if (interface->addr == L1->link_data) create new nexthop; } } two questions - first of all if parent had 4 parallel links to the child above code will create 16 nexthops. no? second isn't interface->addr == L1->link_data check redundant? I would appreciate the clarification. thanks jasmine >> Jasmine, >> The information used immediately is the outgoing >> interface. Besides, at this stage the nexthop >> address can be retrieved from the link data of the >> directly connected router vertex. This nexthop >> address is used later, when a remote vertex >> inherits nexthops to the directly connected router >> vertices. >> Thanks, >> Igor --- j j wrote: >Igor, > >Why is it necessary to record nexthops for routers >connected via network to the root? Where is this >information used? >is it used to process stub links or inter-area >route calcuations? > >thanks > >jasmine > >--- Igor Miroshnik wrote: >> On Sat, 21 Dec 2002 10:46:51 -0800, j j >> wrote: >> >> >hello folks, >> > >> >I am going through Zebra and Moy's source code for >> >OSPFv2. The question I have is when calculating >> >next hops for a router vertex that is directly >> >connected to the root (i.e. calculating router) via >> >a network vertex, why can't we simply inherit the >> >nexthops of the network vertex ? Moy and Zebra both >> >do something special for this case which I cannot >> >understand. >> > >> >It seems like the root should be able to reach the >> >router through all the nexthops that were >> calculated >> >for the network vertex. >> > >> >I hope I was able to clearly explain my doubts. >> > >> >thanks >> > >> >jasmine >> >> Jasmine, >> >> The nexthop address for a router vertex via a >> network one is the IP address of the destination >> router on the network mentioned, whereas the nexthop >> address for a network vertex directly connected >> to the root is not. Actually, the latter does not >> have any nexthop. That is why we can't simply >> inherit the nexthops of that network vertex. In our >> implementation, that nexthop's address is zero. >> >> Thanks, >> Igor __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com From owner-ospf@DISCUSS.MICROSOFT.COM Wed Dec 25 16:51:23 2002 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 QAA21338 for ; Wed, 25 Dec 2002 16:51:23 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.00852B4F@cherry.ease.lsoft.com>; Wed, 25 Dec 2002 16:54:20 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 496340 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 25 Dec 2002 16:54:20 -0500 Received: from 216.136.131.37 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 25 Dec 2002 16:54:20 -0500 Received: from [209.179.216.26] by web10901.mail.yahoo.com via HTTP; Wed, 25 Dec 2002 13:54:20 PST MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20021225215420.67199.qmail@web10901.mail.yahoo.com> Date: Wed, 25 Dec 2002 13:54:20 -0800 Reply-To: Mailing List Sender: Mailing List From: j j Subject: nexthop calculation To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Precedence: list Hello, I had posted a question to the list before but I am not sure if made it or not. So this is a repost. __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com From owner-ospf@DISCUSS.MICROSOFT.COM Wed Dec 25 16:54:40 2002 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 QAA21364 for ; Wed, 25 Dec 2002 16:54:40 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00852B50@cherry.ease.lsoft.com>; Wed, 25 Dec 2002 16:57:43 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 496357 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 25 Dec 2002 16:57:43 -0500 Received: from 216.136.131.37 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 25 Dec 2002 16:57:43 -0500 Received: from [209.179.216.26] by web10901.mail.yahoo.com via HTTP; Wed, 25 Dec 2002 13:57:43 PST MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20021225215743.67517.qmail@web10901.mail.yahoo.com> Date: Wed, 25 Dec 2002 13:57:43 -0800 Reply-To: Mailing List Sender: Mailing List From: j j Subject: nexthop calculation To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Precedence: list Hello, I had posted a question to the list before but I am not sure if made it or not. So this is a repost. Case 1: Router A and B have 4 point to point links connecting them. Should we create 16 nexthops or 4? Case 2: Lets say Router A (root) has 4 connections to a network. And Router B has 4 connections to the same network. When calculating nexthops for RouterB should we create 16 or 4 nexthops? thanks __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com From owner-ospf@DISCUSS.MICROSOFT.COM Tue Dec 31 15:08:26 2002 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 PAA28548 for ; Tue, 31 Dec 2002 15:08:26 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.0085BCAB@cherry.ease.lsoft.com>; Tue, 31 Dec 2002 15:11:32 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 486253 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 31 Dec 2002 15:11:32 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 31 Dec 2002 15:11:32 -0500 Received: from redback.com (login001.redback.com [155.53.12.18]) by prattle.redback.com (Postfix) with ESMTP id 2B0AA3F46E4 for ; Tue, 31 Dec 2002 12:10:32 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <20021225215743.67517.qmail@web10901.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E11FA73.9050707@redback.com> Date: Tue, 31 Dec 2002 15:13:39 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: nexthop calculation To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit j j wrote: > Hello, Hello jj, > > I had posted a question to the list before but I > am not sure if made it or not. So this is a repost. > > Case 1: Router A and B have 4 point to point links > connecting them. Should we create 16 nexthops or 4? 4. How do you get 16? You must be envisioning an implementation that mantains every possible permutation of the four next hops (including the empty one ;^). > > Case 2: Lets say Router A (root) has 4 connections to > a network. And Router B has 4 connections to the same > network. When calculating nexthops for RouterB should > we create 16 or 4 nexthops? I'd say the correct answer is that you aggregate the networks at layer 2 and have a single next hop. However, if must correct multiple IP interfaces to the same network you'd have 4. > > thanks > > > __________________________________________________ > Do you Yahoo!? > Yahoo! Mail Plus - Powerful. Affordable. Sign up now. > http://mailplus.yahoo.com > -- Acee