Liaison statement
Loop Prevention Mechanisms

Submission date 2007-06-26
From ITU-T SG 15 (Greg Jones)
To IETF CCAMP WG (adrian@olddog.co.uk, dbrungard@att.com)
Cc rcallon@juniper.net, dward@cisco.com, sob@harvard.edu, ccamp@ops.ietf.org, sjtrowbridge@alcatel-lucent.com, yoichi.maeda@ntt-at.co.jp
Response contact tsbsg15@itu.int
Technical contact hklam@alcatel-lucent.com
Purpose For action
Deadline 2007-09-01 Action Taken
Attachments Loop Prevention Mechanisms - body text
Body
ITU-T Q14/15 would like to thank IETF CCAMP for the recent liaison containing
the rationale behind the loop prevention method specified in
draft-ietf-ccamp-gmpls-ason-routing-ospf-03.  The rationale provided takes
into account the considerations of how OSPF traditionally operates, but does
not utilize the hierarchical nature defined by ASON.
Since areas in the ASON routing hierarchy are in a parent-child relationship,
the redistribution mechanism between a parent and child area only needs to
consider the direction information is propagating to determine if a loop would
be created.  The direction of propagation is limited to two cases: one for
child to parent and one for parent to child.  The redistribution mechanism
does not need to consider the Area ID of the source, making this information
unnecessary.
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 are also concerned that under the terms of the proposal, the Area ID of the
source will be in all the LSAs carrying information that were shared by
another area.  This means that the Area ID of the source would be stored in
LSDBs located in non-source area.  This storage hampers the ability to change
the Area ID assigned to an area as the LSAs generated by redistribution prior
to the change will not reflect the new Area ID. The redistribution point may
consider the LSAs with the old Area ID as candidates for redistribution, thus
causing a loop. Limiting the information contained in the LSA to just the
propagation direction removes this issue.
ITU-T Q14/15 is glad that work continues on the development of ASON Routing
solutions for our consideration.  We appreciate IETF CCAMP’s consideration
of the issues raised in this liaison, and await their resolution.
An electronic copy of this liaison statement is available at: 
http://ties.itu.ch/ftp/public/itu-t/tsg15opticaltransport/COMMUNICATIONS/