Liaison statement
ASON Routing Loop Prevention Mechanism

The IETF CCAMP working group thanks you for your continued
interest in the loop-prevention mechanism contained in our
OSPF-based solution to the routing requirements as
described in RFC 4258.

This liaison is in response to your liaison COM15-169-E
issued from your June plenary. A separate liaison will
report on the status and progress of our OSPF ASON
solution.

We disagree with your statement that the rationale we
explained "does not utilize the hierarchical nature defined
by ASON." Quite to the contrary, the solution addresses the
issues introduced by the hierarchical routing nature of
ASON while utilizing the benefits. At the same time, since
the protocol mechanisms are extensions to OSPF, it is only
natural that "the rationale provided takes into account the
considerations of how OSPF traditionally operates."

You are right to observe that other mechanisms could have
been selected, and would also have been functional. This is
often the case in protocol design. However, a choice has to
be made, and unless there are technical reasons to suggest
that the choice is wrong, there seems to be no particular
motivation to make a change.

You say:
  While we recognise it is possible to identify the
  propagation direction based on the Area ID of the source,
  it does require that all redistribution mechanisms in the
  network understand the relative location of source areas
  given the area hierarchy (i.e. are they up or down the
  hierarchy from the evaluation point).  We cannot identify
  in the existing proposal any mechanism (i.e. new LSA
  format) defined to provide this information.
We note that the requirement is not to know the direction
of propagation of information, but to detect routing
advertisement loops. According to the strict hierarchical
nature of ASON (as you describe in your liaison) the use
of Area IDs is sufficient to detect advertisement loops.

There is no definition of any new mechanism or LSA in this
Internet-Draft: the use of a new LSA or changes to the
processing rules for existing LSAs would inhibit the
integration of ASON routing developments within the
IETF routing family and, while this may not be an
objective of the ASON architecture, it is an objective of
the IETF.

You suggest that the use of Area ID in the LSAs will
inhibit re-configuration of AREA IDs. We do not believe
that this is the case, and we will add text to the draft to
describe the necessary processing for this important, but
uncommon case.

Please note that the scope of this work (including the
loop-prevention mechanisms) is limited by the requirements
expressed in RFC 4258. A separate liaison to you has
requested a further review of RFC 4258. In the event that
substantive modifications to the requirements are made as a
result of your review, it will be necessary to consider
updating the solutions work. Such a process of publication
and revision is similar to the procedure applied within the
ITU.

Note also that the scope of this work (that is, of this
current Internet-Draft) is extensions to the OSPFv2
protocol. The CCAMP working group would welcome
contributions in the form of Internet-Drafts from anyone
who is interested in addressing the same problem space
through the IS-IS protocol.

Thank you for your continued support of this work.

Regards,
Deborah Brungard and Adrian Farrel
IETF CCAMP Working Group Co-Chairs