Subject: RE: I-D ACTION:draft-ash-multi-area-te-reqmts-01.txt

From: "Ash, Gerald R (Jerry), ALCTA" <[email-masked]>
Date: Mon, 3 Dec 2001 18:48:12 -0500

We would like to call for agreement that

a) draft-ietf-tewg-restore-hierarchy-00.txt calls for multi-area TE
requirements to be generated, but contains no such requirements (Section 3
says "requirements for multi-area traffic engineering need to be developed
to provide guidance for any necessary protocol extensions"), and
b) draft-ash-multi-area-te-reqmts-01.txt be adopted as a multi-area TE
requirements draft.

In addition, Section 6.3 of draft-ietf-tewg-restore-hierarchy-00.txt says
"To support edge-to-edge signaling in the above network scenarios within the
framework of existing horizontal hierarchies, current traffic engineering
(TE) methods [19, 5] may need to be extended. Requirements for multi-area TE
need to be developed to provide guidance for any necessary protocol
extensions."

In regard to 'necessary protocol extensions', there are numerous multi-area
TE approaches, so there is a need to converge on one or a subset of the
approaches (rather than support them all).
draft-ash-multi-area-te-rqmts-01.txt summarizes what protocol extensions
have been proposed by various multi-area TE drafts, including:
http://search.ietf.org/internet-drafts/draft-kompella-mpls-multiarea-te-02.t
xt
http://search.ietf.org/internet-drafts/draft-venkatachalam-interarea-mpls-te
-02.txt
http://search.ietf.org/internet-drafts/draft-vasseur-mpls-computation-rsvp-0
0.txt
http://www.ietf.org/internet-drafts/draft-lee-mpls-path-request-02.txt
http://www.ietf.org/internet-drafts/draft-iwata-mpls-crankback-02.txt.

draft-ash-multi-area-te-rqmts-01.txt also compares the
advantages/disadvantages of each proposed multi-area TE method, and how well
the method meets the proposed requirements.  The analysis can be used to
focus discussion and to select among the approaches.

In summary, we would like to hear any objections to adopting
draft-ash-multi-area-te-rqmts-01.txt as a multi-area TE requirements draft.

Thanks,
Jerry Ash

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, November 30, 2001 6:00 AM
To: IETF-Announce; @wsscan.att.com
Subject: I-D ACTION:draft-ash-multi-area-te-reqmts-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title		: Requirements for Multi-Area TE
	Author(s)	: J. Ash et al.
	Filename	: draft-ash-multi-area-te-reqmts-01.txt
	Pages		: 16
	Date		: 29-Nov-01
	
This draft describes requirements for multi-area TE within the context of
GMPLS.  Based on the requirements, the goal is to eventually provide
protocol extensions needed for multi-area TE.  Various approaches to
multi-area TE are considered, and these approaches are evaluated against the
requirements.  These approaches include state dependent routing (SDR) LSP
selection, event dependent routing (EDR) LSP selection, and time dependent
routing (TDR) LSP selection.  These approaches include needs to support
path-computation server (PCS) functionality, query functionality, crankback
functionality, TE feedback functionality, and summary-LSA functionality. The
target in future releases of this document will be to converge on a reduced
subset of the required multi-area TE methods and protocol
extensions.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ash-multi-area-te-reqmts-01.txt

---

From: Jim Boyle <[email-masked]>
Date: Mon, 3 Dec 2001 23:38:06 -0500 (EST)

Hello, hello, there appears to be an echo in here.
One list please, as this is a discussion of requirements, I'll reply
just to the tewg list.

cheers,

Jim

---

From: Jim Boyle <[email-masked]>
Date: Mon, 3 Dec 2001 23:47:06 -0500 (EST)

> We would like to call for agreement that

I for one will disagree with your proposal of need for additional
(ancillary?) requirements documents at this time.

In the interest of progress, I would suggest we just strike the sentences
which call for more requirements documents (from within the requirements
documents on the matter!) ,  or leave them there and see what's on the
table of technical proposals.  The sentence "... may need to be extended."
captures the scope sufficiently, I'm not sure another 40 pages of
requirements discussion will be of any practical result.

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 4 Dec 2001 08:59:48 -0500

> (ancillary?) requirements documents at this time.

This is fine and simple: fold the multi-area requirements into the base
requirements doc.

My understanding (and your implication below) is that there is a desire to move
forward quickly with the mainline TE requirements.  Our intention with this
draft is to cover the extended requirements in a separate draft so that their
discussion would not block the advance of the main requirements document.

> requirements discussion will be of any practical result.

Without a clear requirements statement a disparate set of protocols will be
developed addressing only bits and pieces of the problem.  The TEWG is clearly
the place to carry out the work of developing the requirements, and these can
then be fed through to CCAMP (or where-ever) to make the protocol changes as
necessary.

Of course it is difficult to gauge the interest in the draft simply from the
list of authors and the emails sent and received external to the TEWG mail-list.
Perhaps you would consent to discuss the need for this work in SLC and move to
adopt the draft if there is sufficient interest (and the draft appears to be
going in the right direction).

Thanks,
Adrian