Skip to main content

Liaison statement
ASON Routing Loop Prevention

Additional information about IETF liaison relationships is available on the IETF webpage and the Internet Architecture Board liaison webpage.
State Posted
Submitted Date 2007-11-16
From Group ccamp
From Contact Adrian Farrel
To Group ITU-T-SG-15-Q14
To Contacts Greg Jones <greg.jones@itu.int>
Cc Stephen Trowbridge <sjtrowbridge@alcatel-lucent.com>
Kam Lam <hklam@alcatel-lucent.com>
Scott Bradner <sob@harvard.edu>
Dave Ward <dward@cisco.com>
Ross Callon <rcallon@juniper.net>
CCAMP Working Group <ccamp@ops.ietf.org>
Response Contact Adrian Farrel <adria@olddog.co.uk>
Deborah Brungard <dbrungard@att.com>
Technical Contact Adrian Farrel <adria@olddog.co.uk>
Deborah Brungard <dbrungard@att.com>
Purpose In response
Attachments (None)
Body
The IETF's CCAMP Working Group thanks you for your liaison entitled
"Liaison Statement to CCAMP on ASON Routing Loop Prevention" issued
from your Stuttgart interim meeting in September 2007.

Your understanding is correct, the Associated Area ID reflects the
area from which the routing information is received. For your
example, it would indicate area C, not area D. As the description
in Section 6.3.1 of our draft was misunderstood, we will add
clarifications.

Thank you for flagging your concerns about reconfiguration
scenarios. As you say in your liaison, the frequency of such
reconfigurations that include a change to the Area ID is unlikely
to be high, but we recognize the importance of making sure such
procedures can be followed without unduly opening up scope for
operator error, and without causing excessive configuration
activity. In this respect, we have been guided by the
reorganization requirements set out in RFC 4258 and the evaluation
scenarios described in RFC 4652. As described in 6.3 of the draft,
the use of the Associated Area ID is only required in scenarios
when more than one RC is bound to an adjacent level of the
hierarchy and both are configured to redistribute routing
information. As the operational aspects remain a concern to you, we
will add text to the draft to further clarify aspects of OSPF
operations for reorganization scenarios.

Please let us know of any remaining operational concerns.

Best regards,

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