Skip to main content

Liaison statement
Loop Prevention Mechanisms

Additional information about IETF liaison relationships is available on the IETF webpage and the Internet Architecture Board liaison webpage.
State Posted
Submitted Date 2007-06-26
From Group ITU-T-SG-15
From Contact Hiroshi Ota
To Group ccamp
To Contacts 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/