[OSPF] RFC1583Compatibility

[Faraz Shamim <[e-mail]>]

Acee,

I would like to know what the rest of the OSPF WG think about this. I want
to see if anyone has implemented it differently.

Requesting for Comments from the rest of the community ;-)

On 4/13/12 10:57 AM, "Faraz Shamim" <[e-mail]> wrote:

>If you read section G.7 of RFC 2178 it appears that
>RFC1583Compatibility would mean to apply 16.4.1 algorithm, for AS
>external 
>if received from multiple area AND change the summary range cost to pick
>up MAXIMUM cost.  But when you read C.1, under RFC1583Compatibility it
>says that this parameter applies to AS external. No where it mentions
>the summary cost should be changed to MINIMUM per RFC 1583. Since G.7
>does not even exist in RFC 2328 so whoever
>reads RFC 2328 would always think that RFC1583Compatibility is ONLY
>related to AS external path preference.
>
>Can you please confirm if RFC1583Compatibility should only affect AS
>external path preference or should it also touch the summary cost and set
>it to MINIMUM per RFC 1583?
>
>Thanks,
>
>Faraz

>From RFC 2178:

G.7 Advertising same external route from multiple areas

   This document fixes routing loops which can occur in RFC 1583 when
   the same external destination is advertised by AS boundary routers in
   separate areas. There are two manifestations of this problem. The
   first, discovered by Dennis Ferguson, occurs when an aggregated
   forwarding address is in use. In this case, the desirability of the
   forwarding address can change for the worse as a packet crosses an
   area aggregation boundary on the way to the forwarding address, which
   in turn can cause the preference of AS-external-LSAs to change,
   resulting in a routing loop.

   The second manifestation was discovered by Richard Woundy. It is
   caused by an incomplete application of OSPF's preference of intra-
   area routes over inter-area routes: paths to any given
   ASBR/forwarding address are selected first based on intra-area
   preference, while the comparison between separate ASBRs/forwarding
   addresses is driven only by cost, ignoring intra-area preference. His
   example is replicated in Figure 19.  Both router A3 and router B3 are
   originating an AS-external-LSA for 10.0.0.0/8, with the same type 2
   metric. Router A1 selects B1 as its next hop towards 10.0.0.0/8,
   based on shorter cost to ASBR B3 (via B1->B2->B3). However, the
   shorter route to B3 is not available to B1, due to B1's preference
   for the (higher cost) intra-area route to B3 through Area A. This
   leads B1 to select A1 as its next hop to 10.0.0.0/8, resulting in a
   routing loop.




Moy                         Standards Track                   [Page 207]

RFC 2178                     OSPF Version 2                    July 1997


   The following two changes have been made to prevent these routing
   loops:

   o   When originating a type 3 summary-LSA for a configured area
       address range, the cost of the summary-LSA is now set to the
       maximum cost of the range's component networks (instead of the
       previous algorithm which set the cost to the minimum component
       cost).  This change affects Sections 3.5 and 12.4.3, Figures 7
       and 8, and Tables 6 and 13.

   o   The preference rules for choosing among multiple AS-
       external-LSAs have been changed. Where previously cost was the
       only determining factor, now the preference is driven first by
       type of path (intra-area or inter-area, through non-backbone area
       or through backbone) to the ASBR/forwarding address, using cost
       only to break ties. This change affects Sections 16.4 and 16.4.1.

   After implementing this change, the example in Figure 19 is modified
   as follows. Router A1 now chooses A3 as the next

                              10.0.0.0/8
                              ----------
                                   |
                                +----+
                                | XX |
                                +----+
                   RIP          /    \        RIP
           ---------------------      --------------------
           !                                             !
           !                                             !
         +----+      +----+       1       +----+......+----+....
         | A3 |------| A1 |---------------| B1 |------| B3 |   .
         +----+   6  +----+               +----+  8   +----+   .
                                           1|  .         /     .
                       OSPF backbone        |  .        /      .
                                          +----+  2    /       .
                                          | B2 |-------  Area A.
                                          +----+................

                Figure 19: Example routing loop when the
            same external route is advertised from multiple
                                 areas

   hop to 10.0.0.0/8, while B1 chooses B3 as next hop. The reason for
   both choices is that ASBRs/forwarding addresses are now chosen based
   first on intra-area preference, and then by cost.


Moy                         Standards Track                   [Page 208]

RFC 2178                     OSPF Version 2                    July 1997


   Unfortunately, this change is not backward compatible. While the
   change prevents routing loops when all routers run the new preference
   rules, it can actually create routing loops when some routers are
   running the new preference rules and other routers implement RFC
   1583.  For this reason, a new configuration parameter has been added:
   RFC1583Compatibility. Only when RFC1583Compatibility is set to
   "disabled" will the new preference rules take effect. See Appendix C
   for more details.




C.1 Global parameters

   In general, a separate copy of the OSPF protocol is run for each
   area.  Because of this, most configuration parameters are defined on
   a per-area basis.  The few global configuration parameters are listed
   below.

[SNIP..]

   RFC1583Compatibility
       Controls the preference rules used in Section 16.4 when choosing
       among multiple AS-external-LSAs advertising the same destination.
       When set to "enabled", the preference rules remain those
       specified by RFC 1583 ([Ref9]). When set to "disabled", the
       preference rules are those stated in Section 16.4.1, which
       prevent routing loops when AS- external-LSAs for the same
       destination have been originated from different areas (see
       Section G.7). Set to "enabled" by default.


       In order to minimize the chance of routing loops, all OSPF
       routers in an OSPF routing domain should have
       RFC1583Compatibility set identically. When there are routers
       present that have not been updated with the functionality
       specified in Section 16.4.1 of this memo, all routers should have
       RFC1583Compatibility set to "enabled". Otherwise, all routers
       should have RFC1583Compatibility set to "disabled", preventing
       all routing loops.