datatracker.ietf.org
Sign in
Version 5.3.0, 2014-04-12
Report a bug

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/