New Liaison Statement, "ASON Routing Loop Prevention"

[Adrian Farrel (IETF CCAMP WG) <adrian@olddog.co.uk>]

Title: ASON Routing Loop Prevention
Submission Date: 2007-11-16
URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=383 

From: Adrian Farrel(IETF CCAMP WG) <adrian@olddog.co.uk>
To: ITU-T Q14/15(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>
Reponse 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 
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
Attachment(s):
No document has been attached