Subject: New Liaison Statement, "Loop Prevention Mechanisms in OSPF for ASON Networks"

From: Adrian Farrel (IETF CCAMP WG) <[email-masked]>
Date: Sun, 06 May 2007 15:19:23 -0400

Title: Loop Prevention Mechanisms in OSPF for ASON Networks
Submission Date: 2007-05-06
URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=326 
Please reply by 2007-07-18

From: Adrian Farrel(IETF CCAMP WG) <[email-masked]>
To: ITU-T SG15 Q14(Greg Jones <[email-masked]>)
Cc: Stephen Trowbridge <[email-masked]>
Kam Lam <[email-masked]>
Dave Ward <[email-masked]>
Ross Callon <[email-masked]>
Acee Lindem <[email-masked]>
Abhay Roy <[email-masked]>
CCAMP Working Group <[email-masked]>
OSPF Working Group <[email-masked]>
Scott Bradner <[email-masked]>
Reponse Contact: Adrian Farrel <[email-masked]>
Deborah Brungard <[email-masked]>
Technical Contact: Adrian Farrel <[email-masked]>
Deborah Brungard <[email-masked]>
Purpose: For action 
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
Attachment(s):
No document has been attached