Subject: [OSPF] OSPF multiple-area network

From: "James Huang" <[email-masked]>
Date: Mon, 25 Jan 2010 13:30:38 -0800

Hi all,

                When a network is connected to multiple areas (maybe as
a stub network), what is the expected behavior according to RFC 2328?

In RFC 2328, a "network" route is always associated with a single area.
But in the following topology, router R will receive two network-LSAs,
one from each attached area:   R is connected to area-1 and area-2.  R's
area-1 neighbor R1 has an interface (part of area-1) connected to a stub
network N.  R's area-2 neighbor R2 has an interface (part of area-2)
also connected to the stub network N. 

                RFC 2328, Sec 16.1, Step (4) has some consideration for
resolving conflicting intra-area network routes.  But is it applicable
to this case?

            If the routing table entry already exists

            (i.e., there is already an intra-area route to the

            destination installed in the routing table), multiple

            vertices have mapped to the same IP network.  For example,

            this can occur when a new Designated Router is being

            established.  In this case, the current routing table entry

            should be overwritten if and only if the newly found path is

            just as short and the current routing table entry's Link

            State Origin has a smaller Link State ID than the newly

            added vertex' LSA.

                Also I do not understand this RFC 2382 logic above.  Why
does it have to compare both the distance and the link state ID.
Suppose there are two possible paths, P1 and P2, to a network.  P1 is
shorter than P2 but P1 has an origin of smaller link state ID.
According to this rule, which path will be installed in the routing
table depends on the order the LSAs are examined.  That seems very
strange to me.

Thanks,

James Huang

---

From: Acee Lindem <[email-masked]>
Date: Mon, 25 Jan 2010 17:47:49 -0500

Hi James,
The excerpted text is referring to multiple LSAs in the same area - not LSAs in different areas. If you read it closely you'll see that the example given is a transient condition. While some vendors do, in fact, support an IP subnet  connected to multiple areas, this is not considered to be a valid topology and is not addressed by RFC 2328. Consider the following excerpt from page 6 of RFC 2328:

        OSPF allows sets of networks to be grouped together.  Such a
        grouping is called an area.  The topology of an area is hidden
        from the rest of the Autonomous System.  This information hiding
        enables a significant reduction in routing traffic.  Also,
        routing within the area is determined only by the area's own
        topology, lending the area protection from bad routing data.  An
        area is a generalization of an IP subnetted network.

Hope this Helps,
Acee

On Jan 25, 2010, at 4:30 PM, James Huang wrote:

Hi all,
                When a network is connected to multiple areas (maybe as a stub network), what is the expected behavior according to RFC 2328?
In RFC 2328, a “network” route is always associated with a single area.  But in the following topology, router R will receive two network-LSAs, one from each attached area:   R is connected to area-1 and area-2.  R’s area-1 neighbor R1 has an interface (part of area-1) connected to a stub network N.  R’s area-2 neighbor R2 has an interface (part of area-2) also connected to the stub network N.

                RFC 2328, Sec 16.1, Step (4) has some consideration for resolving conflicting intra-area network routes.  But is it applicable to this case?

                Also I do not understand this RFC 2382 logic above.  Why does it have to compare both the distance and the link state ID.  Suppose there are two possible paths, P1 and P2, to a network.  P1 is shorter than P2 but P1 has an origin of smaller link state ID.  According to this rule, which path will be installed in the routing table depends on the order the LSAs are examined.  That seems very strange to me.

Thanks,
James Huang

_______________________________________________
OSPF mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ospf

---

From: "James Huang" <[email-masked]>
Date: Mon, 25 Jan 2010 15:35:59 -0800

Hi Acee,

	Thanks for the reply.
	I agreed with you that RFC 2328 assumes each network can only
reside in one area and that is what I always assume too.  But when I
tried to find a scenario to explain the reason for re-running the
complete SPF route computation starting from sec 16.1 in Case 2 of sec
16.5 (incremental updates: summary-LSAs), I just cannot find one unless
there is a multi-area network. If you have one scenario to explain Case
2 of sec 16.5, can you show it?

Thanks,
James Huang

-----Original Message-----
From: Acee Lindem [mailto:[email-masked]] 
Sent: Monday, January 25, 2010 2:48 PM
To: James Huang
Cc: [email-masked]
Subject: Re: [OSPF] OSPF multiple-area network

Hi James,
The excerpted text is referring to multiple LSAs in the same area - not
LSAs in different areas. If you read it closely you'll see that the
example given is a transient condition. While some vendors do, in fact,
support an IP subnet  connected to multiple areas, this is not
considered to be a valid topology and is not addressed by RFC 2328.
Consider the following excerpt from page 6 of RFC 2328:

Hope this Helps,
Acee

Hi all,

Thanks,
James Huang

---

From: Acee Lindem <[email-masked]>
Date: Mon, 25 Jan 2010 19:12:43 -0500

Hi James,

> 2 of sec 16.5, can you show it?

If the path through the transit area was used to update intra-area path through the backbone as described in 16.3 and now the cost of a transit area path increases, you must rerun the intra-area SPF which, in the case of RFC 2328, implies rerunning the complete SPF. This isn't to say that the intra-area portion couldn't be done incrementally as well but it isn't described in RFC 2328. 

Hope this helps, 
Acee

---

From: "James Huang" <[email-masked]>
Date: Mon, 25 Jan 2010 17:07:08 -0800

Hi Acee,
	I thought Sec 16.5 is about receiving a new summary LSA for a
network N. It is not about transit area path changes (in which case it
will be new router-LSAs or new network-LSAs for the transit area).  

Let's say network N is in one region of area 0 (area0-a), the transit
area is area 1, and the virtual link in area 1 connects area-0a to
another region of area-0 (area0-b) from ABR router R1 to ABR router R2.
ABR router R3 connects to area-0b and area-1. When R3 receives a new
summary-LSA for N from R2 that increases the cost to N, R3 needs to
re-compute 16.1/16.2 for area-0 and 16.3 for network N (for network N
and all destinations in area-0a reachable through N).  Why does R3 have
to re-compute intra-area routes for area-1 or any other areas it
attaches to?  

This brings up another question: why sec 16.3 does not mention about
re-computing area 0's intra-area routes for those destinations behind N
if it find a better route to N than what was originally found in
16.1/16.2? 

Thanks,
James Huang            

-----Original Message-----
From: Acee Lindem [mailto:[email-masked]] 
Sent: Monday, January 25, 2010 4:13 PM
To: James Huang
Cc: [email-masked]
Subject: Re: [OSPF] OSPF multiple-area network

Hi James,

> 2 of sec 16.5, can you show it?

If the path through the transit area was used to update intra-area path
through the backbone as described in 16.3 and now the cost of a transit
area path increases, you must rerun the intra-area SPF which, in the
case of RFC 2328, implies rerunning the complete SPF. This isn't to say
that the intra-area portion couldn't be done incrementally as well but
it isn't described in RFC 2328. 

Hope this helps, 
Acee

---

From: Acee Lindem <[email-masked]>
Date: Tue, 26 Jan 2010 19:50:18 -0500

Hi James,
Thanks,
Acee

> to re-compute intra-area routes for area-1 or any other areas it

It probably doesn't. As I previously stated, RFC 2328 doesn't attempt to describe all the possible incremental SPF optimizations .  This is explicitly stated in section 16.1 on page 167:

        The specification does not require that the above two stage
        method be used to calculate the shortest path tree.  However, if
        another algorithm is used, an identical tree must be produced.
        For this reason, it is important to note that links between
        transit vertices must be bidirectional in order to be included
        in the above tree.  It should also be mentioned that more
        efficient algorithms exist for calculating the tree; for
        example, the incremental SPF algorithm described in [Ref1].

Also note footnote [19] on page 181:

    [19]By keeping more information in the routing table, it is possible
    for an implementation to recalculate the shortest path tree for only
    a single area.  In fact, there are incremental algorithms that allow
    an implementation to recalculate only a portion of a single area's
    shortest path tree [Ref1].  However, these algorithms are beyond the
    scope of this specification.
Thanks,
Acee

---

From: "James Huang" <[email-masked]>
Date: Tue, 26 Jan 2010 18:00:45 -0800

Hi Acee,
	Got it.
Thanks,
James Huang

-----Original Message-----
From: Acee Lindem [mailto:[email-masked]] 
Sent: Tuesday, January 26, 2010 4:50 PM
To: James Huang
Cc: [email-masked]
Subject: Re: [OSPF] OSPF multiple-area network

Hi James,
Thanks,
Acee

> to re-compute intra-area routes for area-1 or any other areas it

It probably doesn't. As I previously stated, RFC 2328 doesn't attempt to
describe all the possible incremental SPF optimizations .  This is
explicitly stated in section 16.1 on page 167: