Comments on Requirements Design Team I-D: "Network Hierarchy and Multilayer Survivability"

["Ash, Gerald R (Jerry), ALCTA" <gash@att.com>]

All,

Here are some comments and suggestions on the Requirements Design Team I-D
http://search.ietf.org/internet-drafts/draft-team-tewg-restore-hierarchy-00.
txt. 

I think some of the requirements need to be made more explicit.  The reason
is that for work to be carried to CCAMP, I think one needs to demonstrate
that the "DT requires the protocol work". 

In regard to requirements for multi-area TE and crankback, here are a few of
the references the DT Requirements draft now makes, which I think are
related to the "requirements":

In Section 6.1:
 Some proposals on improved mechanisms to address network hierarchy
   have been suggested [6, 7, 8].  This document aims to provide the
   concrete requirements so that these and other proposals can first
   aim to meet some limited objectives.

In Section 6.2:
Networks which would like to signal edge-to-edge, and might even
     scale in a limited application. However, they are hierarchically
     routed (e.g. OSPF areas) and current implementations, and
     potentially standards prevent signaling across areas.  This
     requires the development of signaling standards that support
     dynamic establishment and potentially restoration of LSPs across a
     2-level IGP hierarchy.

In Section 7:
However, the concept of network elements that
   participate on both sides of a boundary might be a consideration
   (e.g. OSPF ABRs).  That would allow for devices on either side to
   take an intra-area approach within their region of knowledge, and
   for the ABR to do this in both areas, and splice the two protected
   connections together at a common point (granted it is a common point
   of failure now).  If the limitations of this approach start to
   appear in operational settings, then perhaps it would be time to
   start thinking about route-servers and signaling propagated
   directives. 

All these references allude to the need to support multi-area TE, but are
not explicit in actually requiring the protocol work go forward in CCAMP.
So I think the multi-area TE requirements
http://search.ietf.org/internet-drafts/draft-ash-ccamp-multi-area-te-reqmts-
00.txt, which calls also for crankback
http://search.ietf.org/internet-drafts/draft-iwata-mpls-crankback-01.txt in
all alternative multi-area TE approaches, should be more explicitly
"required" as the basis for the protocol work to proceed in CCAMP.  The
justification would then be that the Requirements DT output "requires this
protocol extensions work go forward".

I don't think this comment is only limited to multi-area TE and crankback,
but could apply also to restoration topics and perhaps other areas.

Thanks,
Jerry Ash
AT&T Labs
Middletown, NJ USA