Acee, Faraz, It is hard to believe there are any RFC 1583 implementations still in operation. It is true that back when RFC 2178 (and later RFC 2328) was published, the WG was dealing with two real routing loop issues. However it seems academic now. Can't RFC1583Compatibility simply be retired along with RFC 1583?
As for John's text, > 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. I feel fairly confident the "new preference rules" refer to Section 16.4.1. It seems unlikely that leaving the summary cost at MAXIMUM when RFC1583Compatiblility is set to "enabled" would create more routing loops. Indeed the opposite seems true. My guess is this omission in RFC 2328 was intentional. I did hear the discussion about backward compatibility and I don't remember any mention of the summary cost change. Pat > 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 _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
