Liaison statement
Loop Prevention Mechanisms in OSPF for ASON Networks

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