Draft liaison to ITU on Loop Prevention in ASON Routing

["Adrian Farrel" <adrian@olddog.co.uk>]

Hi,

CCAMP asked us a specific question with regard to loop prevention in OSPF 
ASON Routing and why we had chosen not to use the mechanisms provided for 
loop prevention in IS-IS for IP and MPLS-TE.

Here is a draft response. (Thanks to Deborah, Dimitri, Acee, and Abhay for 
help in preparing it.)

Please let me have your comments by Saturday 5th April.

Thanks,
Adrian

===

To: ITU-T Q14/15
From: IETF CCAMP Working Group
Cc: Stephen Trowbridge, Kam Lam, Dave Ward, Ross Callon, Acee
Lindem, Rohit Dube, CCAMP Working Group, OSPF Working Group
Subject: Loop Prevention Mechanisms in OSPF for ASON Networks
For Action

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 RFC 1195 [2].

   This document extends the semantics presented in RFC 1195 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 layer 1 area is dual
homed to the IS-IS layer 2 area and the prefixes advertised from
one layer into the other at one L1L2 router (Ra) are re-advertised
back into the originating IS-IS layer 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 layers.
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 layers.
This means that TE information can be exchanged between IS-IS
layers, 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 layer 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-dimitri-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-dimitri-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-
dimitri-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