Re: Seeming contradiction on forwarding addresses?

Acee Lindem <acee@REDBACK.COM> Tue, 14 October 2003 19:37 UTC

Received: from LIME.ease.lsoft.com (lime.ease.lsoft.com [209.119.0.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26531 for <ospf-archive@LISTS.IETF.ORG>; Tue, 14 Oct 2003 15:37:48 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.1.37) by LIME.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.0001FE37@LIME.ease.lsoft.com>; Tue, 14 Oct 2003 15:33:54 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 57896085 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 14 Oct 2003 15:37:41 -0400
Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 14 Oct 2003 15:37:39 -0400
Received: from redback.com (pptp-6-156.redback.com [155.53.6.156]) by prattle.redback.com (Postfix) with ESMTP id F1F486F03CE for <OSPF@PEACH.EASE.LSOFT.COM>; Tue, 14 Oct 2003 12:37:37 -0700 (PDT)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
References: <OF77F1317B.9E8A0DFF-ON85256DBF.00624EE8-85256DBF.00642C3C@us.ibm.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Message-ID: <3F8C507E.5060008@redback.com>
Date: Tue, 14 Oct 2003 15:37:34 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Acee Lindem <acee@REDBACK.COM>
Subject: Re: Seeming contradiction on forwarding addresses?
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To: <OF77F1317B.9E8A0DFF-ON85256DBF.00624EE8-85256DBF.00642C3C@us.ibm.com>
Precedence: list
Content-Transfer-Encoding: 7bit

Hi Mike - See inline below:

Mike Fox wrote:

>Acee wrote:
>
>
>
>>the forwarding address itself
>>must be reachable
>>by an OSPF intra-area or inter-area route (which is by definition part
>>of the OSPF routing
>>domain).  In this context, I prefer to use the term OSPF routing domain
>>rather than AS since
>>there will often be non-OSPF routes in use within an AS running OSPF as
>>the IGP.
>>
>>
>
>This still does not resolve the contradiction.   RFC 2328 contains the
>following text in section 2.3:
>
>
>====begin quoted text=====
>For example,
>suppose in Figure 2 there is an additional router attached to
>Network N6, called Router RTX.  Suppose further that RTX does
>not participate in OSPF routing, but does exchange BGP
>information with the AS boundary router RT7.  Then, Router RT7
>would end up advertising OSPF external routes for all
>destinations that should be routed to RTX.  An extra hop will
>sometimes be introduced if packets for these destinations need
>always be routed first to Router RT7 (the advertising router).
>
>To deal with this situation, the OSPF protocol allows an AS
>boundary router to specify a "forwarding address" in its AS-
>external-LSAs.  In the above example, Router RT7 would specify
>RTX's IP address as the "forwarding address" for all those
>destinations whose packets should be routed directly to RTX.
>====end quoted text====
>
>Since RTX is not participating in OSPF routing, a route to it would not be
>internal to the OSPF AS (or routing domain if you prefer).  Yet this text
>says to use RTX's address as the forwarding address.
>
RTX can have be connected to a mult-access network running OSPF even if
it doesn't run
OSPF itself. For example, let's say the subnet address is 192.168.2.0/24
and RTX's
address on N6 is  192.168.2.55. There will still be an OSPF route to
192.168.2.0/24 in
the route tables for all the OSPF routers.


>    Because of the
>other requirement that the forwarding address be reachable via an OSPF
>internal path, no other router would be able to use this AS External
>advertisement.
>
>This becomes more of a problem in IPv6 but it also causes problems in IPv4.
>Consider this example, modified from the RFC:
>
>
>                                |
>                      +---+     |
>                      |RTA|-----|     +---+
>                      +---+     |-----|RTX|
>                                |     +---+
>                      +---+     |
>                      |RTB|-----|
>                      +---+     |
>                                |
>                      +---+     |
>                      |RTC|-----|
>                      +---+     |
>                                |
>                                +
>
>RTA-RTC are running OSPF.  RTX is not.  RTA advertises an AS external
>default route with a forwarding address of RTX.   In IPv4, that forwarding
>address would be in the network's subnet so even though RTX is not running
>OSPF, RTB and RTC learn OSPF subnet routes that would allow packets to be
>forwarded to RTX.  However if the system programmer coded a static route to
>RTX on RTB or RTC, that route would be more specific than the OSPF subnet
>route,  so it would be found when looking up RTX, and since it's not
>internal to the OSPF domain the default route becomes unusable by RTB and
>RTC.
>
The OSPF specification only considers OSPF routes when doing the lookup.
Implementations
that do not maintain a separate OSPF route table or multiple routes (in
order of preference) will
have to  use a modified  route lookup.

>
>In IPv6 the situation gets worse because there is no requirement for all
>addresses on the link to fall into the same prefix.  RTX could have a
>global address that is not in any prefix known by the other routers,
>requiring a static route to be coded -- but if the route to RTX is static
>(i.e., not OSPF), that makes it unusable as a forwarding address for any AS
>external LSAs.
>
Nope - even if the prefix is configured on all the OSPFv3 routers it
still should be installed in
every OSPFv3 since it will be advertised in the intra-area prefix LSA
which refers to the
network LSA (the DR originates both of these).

The biggest issue that I see with forwarding addresses in OSPFv3 is that
if other IPv6 protocols
install link local  next-hops (like OSPFv3 does), they'll  rarely be
advertised.

>
>Why not simply require that the forwarding address be reachable, period?
>The route could be static, RIP, BGP or whatever.  As long as it's possible
>to route to the forwarding address, why be picky about the type of route?
>
Because if it isn't an OSPF path we can't be sure that other routers in
the OSPF routing domain  have
reachability to the forwarding address and it is better to use the route
to the ASBR.


>
>Mike
>-----------------------------------------------------------------------
>Enterprise Network Solutions
>-----------------------------------------------------------------------
>Research Triangle Park, NC  USA
>
>
>