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