Liaison statement
Loop Prevention Mechanisms in OSPF for ASON Networks
Additional information about IETF liaison relationships is available on the
IETF webpage
and the
Internet Architecture Board liaison webpage.
State | Posted |
---|---|
Submitted Date | 2007-05-06 |
From Group | ccamp |
From Contact | Adrian Farrel |
To Group | ITU-T-SG-15-Q14 |
To Contacts | Greg Jones <greg.jones@itu.int> |
Cc | Stephen Trowbridge <sjtrowbridge@alcatel-lucent.com> Kam Lam <hklam@alcatel-lucent.com> Dave Ward <dward@cisco.com> Ross Callon <rcallon@juniper.net> Acee Lindem <acee@redback.com> Abhay Roy <akr@cisco.com> CCAMP Working Group <ccamp@ops.ietf.org> OSPF Working Group <ospf@ietf.org> Scott Bradner <sob@harvard.edu> |
Response Contact | Adrian Farrel <adrian@olddog.co.uk> Deborah Brungard <dbrungard@att.com> |
Technical Contact | Adrian Farrel <adrian@olddog.co.uk> Deborah Brungard <dbrungard@att.com> |
Purpose | For action |
Deadline | 2007-07-18 Action Taken |
Attachments | (None) |
Body |
The CCAMP Working Group thanks you for your liaison "Liaison Statement to CCAMP responding to ccamp liaison of 21 February 2007" generated at your Darmstadt interim meeting and dated March 2007. This liaison continues an exchange about the loop prevention mechanisms introduced to in draft-ietf-ccamp-gmpls-ason- routing-ospf-03.txt "OSPFv2 Routing Protocols Extensions for ASON Routing". In your liaison "Response to IETF CCAMP WG LS (TD314/3) on "Notification of work in the IETF CCAMP working group" dated November 2006 you said: As discussed within Section 6 on routing information dissemination, and per the ASON link state routing requirements in G.7715.1, it is essential to avoid feedback loops that may arise when both upward and downward communication interfaces contain endpoint reachability information. Thus, we fully agree that providing associated import/export rules is an essential element of OSPF routing protocol design. In reviewing Sections 6.1 - 6.5 of the draft, we observed that several new mechanisms are being proposed to address this important problem. It was observed that RFC 2966, which has already considered and addressed such issues, appears to contain an applicable, relatively simple solution mechanism (within Section 3.1) that is not specific to the IS-IS protocol. Given RFC 2966 offers a solution that has been proven and implemented by multiple vendors, yielding the potential opportunity for reuse, we wondered whether you had identified any drawbacks in pursuing such an approach. Please provide us with your thoughts on the usage of this alternative method. In our response liaison "Response to your liaison on current ASON work in CCAMP" dated 21st February 2007 we replied: We are glad that you agree with our assessment that it is an essential element of OSPF routing protocol design to provide import/export rules to prevent feedback loops. RFC2966 presents a solution to this problem specific to the ISIS protocol, although, as you say, this mechanism could be adapted to other protocols. But other mechanisms also exist, and the ultimate solution that we choose must be agreed not by the ISIS community, but by the OSPF community. In this case, the choice was made after careful evaluation in cooperation with IETF's OSPF Working Group. Please let us know whether you have any technical issues with the approach we have chosen, and if so, what the issues are. In your most recent liaison, you say: On the selection of a loop prevention mechanism the liaison statement indicates that "the choice was made after careful evaluation in cooperation with IETF's OSPF Working Group." We would appreciate further details of these considerations to allow us to fully understand the thought going into this decision and evaluate any impacts on the transport network. We are happy to provide a summary of the decision. RFC 2966 is titled "Domain-wide Prefix Distribution with Two- Level IS-IS", and the Abstract reads: This document describes extensions to the Intermediate System to Intermediate System (IS-IS) protocol to support optimal routing within a two-level domain. The IS-IS protocol is specified in ISO 10589, with extensions for supporting IPv4 (Internet Protocol) specified in RFC1195. This document extends the semantics presented in RFC1195 so that a routing domain running with both level 1 and level 2 Intermediate Systems (IS) [routers] can distribute IP prefixes between level 1 and level 2 and vice versa. This distribution requires certain restrictions to insure that persistent forwarding loops do not form. The goal of this domain-wide prefix distribution is to increase the granularity of the routing information within the domain. The problem that RFC 2966 addresses is for a two level domain. The problem is that, because of the way IS-IS is defined to exchange IP prefixes between levels, it is possible that a routing loop could be formed. The issue arises when an IS-IS level 1 routing area is dual homed to the IS-IS level 2 routing area and the prefixes advertised from one level into the other at one L1L2 router (Ra) are re-advertised back into the originating IS-IS level at another L1L2 router (Rb) making it appear that the shortest path to a prefix from Rb is through Ra. The fix in RFC 2966 uses the up/down bit to make sure that advertisements do not continually circulate between levels. RFC 3784 "Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)" defines traffic engineering information distribution mechanisms using IS-IS. This work is further extended by RFC 4205 "Intermediate System to Intermediate System (IS-IS) Extensions in Support of Generalized Multi- Protocol Label Switching (GMPLS)". RFC 3784 allows the extended reachability TLV to be exchanged between IS-IS levels. This means that TE information can be exchanged between IS-IS levels, and the up/down bit is necessary to stop the advertisements circulating for ever. But, it is important to note that since the TE information is used to build a topology representation in the Traffic Engineering Database, there is no risk of data looping. Contrast this with the problem addressed in RFC 2966 where shortest path first computations provided per IS-IS level might cause data looping. Thus, the only problem addressed by the use of the up/down bit in RFC 3784 is that of endlessly circulating information. Now, OSPF addresses the original looping problem in a different way. It restricts the advertisement of prefixes between areas by using different LSA types and flooding scopes. Thus, information leaked from Area 0 into some other subtended area is never leaked back into Area 0. Further in OSPF-TE, there is no danger of endlessly looping information between Area 0 and the subtended areas because RFC 3630 "Traffic Engineering (TE) Extensions to OSPF Version 2" instructs us to use the type 10 opaque LSA for distributing TE information. And, as defined in RFC 2370 "The OSPF Opaque LSA Option" a type 10 opaque LSA is not distributed outside the area in which it was generated. The problem that must be addressed in draft-ietf-ccamp-gmpls- ason-routing-ospf is caused because of a deliberate change in information leakage processing. That is, in the ASON network, selected upward and downward redistribution of TE information is allowed. Thus, OSPF-TE is opened up to the possibility of information distribution looping (although still not of looping of computed data paths). As section 6.3 of draft-ietf-ccamp-gmpls-ason-routing-ospf- 03.txt says: When more than one RC are bound to adjacent levels of the hierarchy, configured and selected to redistribute upward and downward the routing information, a specific mechanism is required to avoid looping/re-introduction of routing information back to the upper level. This specific case occurs e.g. when the RC advertising routing information downward the hierarchy is not the one advertising routing upward the hierarchy (or vice-versa). When these conditions are met, it is necessary to have a means by which an RC receiving an Opaque TE LSA imported/ exported downward by an RC associated with the same area, suppresses the import/export back of the content of this LSA upward into the (same) upper level. Clearly it is necessary to add some indication of the origin of the data into the advertisement. The mechanism proposed in draft-ietf-ccamp-gmpls-ason-routing-ospf-03.txt is to add the Area ID of the OSPF area containing the originating RC. This provides more information than the simple up/down bit of RFC 2966 and allows an easy distinction to be made between advertising information received from a lower layer area down into a different lower layer area, and back into the same lower layer area. We hope this clarifies the similarities and differences with RFC 2966, and hope that you will ask if you have further specific questions. As before, we encourage you to examine the resulting functionality and to provide us with technical arguments if you believe the function is inappropriate for a transport network, or if you see any specific issues with the proposed approach. Best regards, Adrian Farrel and Deborah Brungard IETF CCAMP Working Group Co-Chairs |