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

From: "Ash, Gerald R (Jerry), ALCTA" <[email-masked]>
Date: Tue, 14 Aug 2001 22:06:41 -0400

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

---

From: Jim Boyle <[email-masked]>
Date: Thu, 16 Aug 2001 23:50:04 -0400 (EDT)

If I read this right, I can recapture it's assertions as:

	- Some of the requirements can be met at a high level by some
          of the previous protocol proposals
	- Indeed, perhaps nothing may be required to change from a
          protocol perspective
	- We won't know until we start some initial tinkering /
          prototyping / groundwork development, here in TE.

I agree with the first two.  The last one, however, seriously
conflicts our stated approach to this.  One that there appeared to be
support for in the London meeting, but one that at least has support
with our ADs and the affected WG chairs.  That approach is as follows.

   The Internet Traffic Engineering WG is developing the requirements
   for restoration and hierarchy in operational Internet TE networks.
   We will also be considering input from other WGs, most notably IPO,
   though the initial scope of work handed to CCAMP is desired to be
   narrow, not broad.  It is to be requirements.  We are not
   endeavoring to host the response of protocol proposals to meet
   those requirements.  Those protocol discussions will be coordinated
   (and hosted as appropriate) by CCAMP.

So, at this time, let's focus on the requirements for what need be
standardized, interoperable and actively deployed in the not too
distant future.

Once we tag team these over to CCAMP, then the real fun can begin :)

regards,

Jim