Re: Comments on Requirements Design Team I-D: "Network Hierarchyand Multilayer Survivability"

[Jim Boyle <jimpb@nc.rr.com>]

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




On Tue, 14 Aug 2001, Ash, Gerald R (Jerry), ALCTA wrote:

> 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
>