Re: [OSPF] RFC1583Compatibility

[Acee Lindem <[e-mail]>]

Hi Faraz,

On Apr 13, 2012, at 12:16 PM, Faraz Shamim wrote:

> 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?

I agree that RFC1583Compatibility should only affect AS external path preference. This is also the interpretation in my implementation and the open source quagga implementation. 

Thanks,
Acee 





>> 
>> 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.
> 
> 
> 
> _______________________________________________
> OSPF mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ospf