Subject: Re: Inter-area routes reachable via multiple areas

From: Vivek Dubey <[email-masked]>
Date: Wed, 10 Sep 2003 10:13:25 -0000

The case should not occur in case of standard ABR implementations for inter-area route calculations.
CISCO/IBM ABR implementations might lead to such scenario.

Vivek

On Wed, 10 Sep 2003 Liu Yu wrote :
>Hi! all
>
>I notice that the clause in  RFC 2328 16.4 (3) is just for external route.
>How about "inter-area routes"ï¼Ÿ RFC 2328 does not explicitly state this
>one! Just choose the "the path whose associated area has the
>largest OSPF Area ID "ï¼Ÿï¼Ÿ Maybe every one has his own implentation.
>
>
>thanks!
>
>
>----- Original Message -----
> From: "Acee Lindem" <[email-masked]>
>To: <[email-masked]>
>Sent: Friday, August 01, 2003 5:46 AM
>Subject: Re: ASBR reachable via multiple areas
>
>
> > Rob,
> >
> > You are correct - I missed that clause in 16.4 (3) when
> > re-reading. I should have checked my implementation before
> > replying. I can't envision why installing an equal-costs
> > routes through multiple areas using the same 16.4.1 selection
> > rules could cause a routing loop or other problem.
> >
> > Thanks,
> > Acee
> >
> > ROB PATH wrote:
> > > --- Acee Lindem <[email-masked]> wrote:
> > >
> > >>Igor Miroshnik wrote:
> > >>
> > >>>All,
> > >>>
> > >>>   RFC 1583 states: "AS boundary router's routing
> > >>
> > >>table entry must indicate a set of paths which
> > >>
> > >>>utilize a single area." (16.1)
> > >>>   Why not utilize all equal-cost paths through
> > >>
> > >>different areas?
> > >>
> > >>Hi Igor,
> > >>
> > >>I believe you can calculate equal cost paths through
> > >>multiple
> > >>areas - read section 16.4 and 16.4.1 in RFC 2328
> > >>(which
> > >>obsoletes RFC 2178 which obsoletes RFC 1583).
> > >>
> > >>
> > >
> > >
> > > The section 16.4 in RFC 2328 does not explicitly state
> > > that equal cost paths through multiple areas could be
> > > utilized (say for load balancing purposes).
> > >
> > > It rather states that when there are multiple
> > > least cost paths available in the routing
> > > table, the path whose associated area has the
> > > largest OSPF Area ID is chosen.
> > >
> > > Also section 16.4.1 refers to section 16.4 for
> > > choosing a path based on cost, when there are
> > > multiple paths of equal highest preferences.
> > >
> > > So it essentially means that multiple equal cost
> > > inter-area paths are not utilized.
> > >
> > > Thanks,
> > >     Rob.
> > >
> > >
> > >
> > >>
> > >>>   Thanks,
> > >>>   Igor
> > >>>
> > >>
> > >>
> > >>--
> > >>Acee
> > >
> > >
> > >
> > > =====
> > > Rob Path
> > > E-Mail : [email-masked]
> > >
> > > __________________________________
> > > Do you Yahoo!?
> > > Yahoo! SiteBuilder - Free, easy-to-use web site design software
> > > http://sitebuilder.yahoo.com
> > >
> >
> >
> > --
> > Acee
>

___________________________________________________
Medicine meets Marketing; Dr. Swati Weds Jayaram.
Rediff Matchmaker strikes another interesting match !!
Visit http://rediff.com/matchmaker?2

---

From: Liuyu <[email-masked]>
Date: Mon, 15 Sep 2003 11:14:47 +0800

I have read RFC 3509:Alternative Implementations of OSPF Area Border Routers

But it still does not explicitly state how to  choose a inter-area route from multi associated areas.

For example:
R3 attaches to Area 2 and Area 1, but it is not a ABR acrroding to RFC 3509.
When R3 caculate the route to inter-area route Net K, it will find one with next hop to R2
with metric equal to 4 in Area 1 and the other one with next hop set to R4 with the same metric.

How will R3 install the inter-area route Net K in its routing table?  Huawei's VRP will choose the latest
caculated route.

As you konw , the ECMP in OSPF must  be the same type and in the same area.

Thanks a lot!

                      .        Backbone         .
                     .           Net K           .
                     .   ---------------------   .
                      .   |1               1|   .
                       ..+--+.............+--+..
                       ..|R1|.....    ....|R4|..
                      .  +--+     .  .    +--+  .
                      .   1|      .  .     /4   .
                      .    |    2 +--+ 4  /     .
                      .    |    +-|R3|---+      .
                      .   1|   /  +--+\4        .
                      .  +--+ /   .  . \ 4 +--+ .
                      .  |R2|/2   .  .  +--|R5| .
                      .  +--+     .  .     +--+ .
                      .   |       .  .       |  .
                      . --------- .  . -------- .
                      .   net N   .  .  net M   .
                      .           .  .          .
                      .  Area 1   .  .  Area 2  .
                       ...........    ..........

----- Original Message ----- 
From: "Vivek Dubey" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, September 10, 2003 6:13 PM
Subject: Re: Inter-area routes reachable via multiple areas

Vivek

On Wed, 10 Sep 2003 Liu Yu wrote :
>How about "inter-area routes"ï¼Y RFC 2328 does not explicitly state this
>largest OSPF Area ID "ï¼Yï¼Y Maybe every one has his own implentation.
>
>
>thanks!
>
>

---

From: Acee Lindem <[email-masked]>
Date: Tue, 16 Sep 2003 15:13:19 -0400

> As you konw , the ECMP in OSPF must  be the same type and in the same area.

Note that RFC 3509 is an informational RFC and not a standard. Therefore, you
shouldn't treat it as such. In this situation, I see no reason why you couldn't
install an ECMP route.

--
Acee

---

From: Liu Yu <[email-masked]>
Date: Thu, 18 Sep 2003 09:51:31 +0800

Acee :

Please read the following :

RFC 2328: OSPF 

Section 16.8 Equal-cost multipath
"
Each one of the multiple routes will be	of the same type
	(intra-area, inter-area, type 1	external or type 2 external),
	cost, and will have the same associated	area.  However, each
	route may specify a separate next hop and Advertising router."

Thanks!

---

From: Acee Lindem <[email-masked]>
Date: Wed, 17 Sep 2003 23:01:33 -0400

> Please read the following :

       Liu  :

   Then don't implement RFC 3509 since by definition it
   deviates from RFC 2338.

--
Acee