Please publish draft-ietf-ccamp-te-node-cap-05.txt

"Adrian Farrel" <adrian@olddog.co.uk> Thu, 05 April 2007 09:17 UTC

Return-path: <owner-ccamp@ops.ietf.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZO5b-0003uu-Qf for ccamp-archive@ietf.org; Thu, 05 Apr 2007 05:17:07 -0400
Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZO5W-0003g4-9Q for ccamp-archive@ietf.org; Thu, 05 Apr 2007 05:17:07 -0400
Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from <owner-ccamp@ops.ietf.org>) id 1HZNyY-0008U4-B0 for ccamp-data@psg.com; Thu, 05 Apr 2007 09:09:50 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com
X-Spam-Level:
X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.7
Received: from [212.23.3.140] (helo=pythagoras.zen.co.uk) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from <adrian@olddog.co.uk>) id 1HZNyE-0008Sx-Uh for ccamp@ops.ietf.org; Thu, 05 Apr 2007 09:09:32 +0000
Received: from [88.96.235.142] (helo=cortex.aria-networks.com) by pythagoras.zen.co.uk with esmtp (Exim 4.50) id 1HZNyB-0007pv-Es for ccamp@ops.ietf.org; Thu, 05 Apr 2007 09:09:27 +0000
Received: from your029b8cecfe ([194.54.8.87] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Apr 2007 10:09:26 +0100
Message-ID: <027901c77762$1ace8170$0a23fea9@your029b8cecfe>
Reply-To: Adrian Farrel <adrian@olddog.co.uk>
From: Adrian Farrel <adrian@olddog.co.uk>
To: Ross Callon <rcallon@juniper.net>
Cc: ccamp@ops.ietf.org, "Brungard, Deborah A, ALABS" <dbrungard@att.com>
Subject: Please publish draft-ietf-ccamp-te-node-cap-05.txt
Date: Thu, 05 Apr 2007 10:09:14 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="iso-8859-1"; reply-type="original"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-OriginalArrivalTime: 05 Apr 2007 09:09:27.0010 (UTC) FILETIME=[1C630420:01C77762]
X-Originating-Pythagoras-IP: [88.96.235.142]
Sender: owner-ccamp@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 21be852dc93f0971708678c18d38c096

Hi Ross,

draft-ietf-ccamp-te-node-cap-05.txt has completed CCAMP working group last
call and has been updated accordingly.

The CCAMP working group requests publication as a Standards Track RFC.

Proto Write-up according to
https://rtg.ietf.org/area/procedures/proto_wgchair_writeup is found below.

Thanks,
Adrian

===

draft-ietf-ccamp-te-node-cap-05.txt

Adrian Farrel is willing to be Proto Shepherd for this I-D

> 1. Have the chairs personally reviewed this version of
>    the Internet Draft (ID), and in particular, do they
>    believe this ID is ready to forward to the IESG for
>    publication?

This I-D received WG chair review by Adrian prior to WG last call.
The last call mark-ups were checked by Adrian.

The chairs believe this I-D is ready to move forward.

> 2. Has the document had adequate review from both key WG
>    members and key non-WG members? Do you have any
>    concerns about the depth or breadth of the reviews
>    that have been performed?

The document is authored by some key WG members and received constructive
comments from across the WG during its development.

The document was shown to the OSPF and ISIS working groups more than once,
and the last call was notified to the two IGP working groups.

The chairs have no concerns about the depth of review.

> 3. Do you have concerns that the document needs more
>    review from a particular (broader) perspective (e.g.,
>    security, operational complexity, someone familiar
>    with AAA, etc.)?

The chairs have no such concerns.

> 4. Do you have any specific concerns/issues with this
>    document that you believe the ADs and/or IESG should
>    be aware of? For example, perhaps you are
>    uncomfortable with certain parts of the document, or
>    have concerns whether there really is a need for it.
>    In any event, if your issues have been discussed in
>    the WG and the WG has indicated it that it still
>    wishes to advance the document, detail those concerns
>    in the write-up.

The chairs have no such concerns.

> 5. How solid is the WG consensus behind this document?
>    Does it represent the strong concurrence of a few
>    individuals, with others being silent, or does the WG
>    as a whole understand and agree with it?

The working group has been relatively quiet on this work, but the chairs
judge that to be because it is "done and dusted". It is a small protocol
feature that does not need significant debate.

> 6. Has anyone threatened an appeal or otherwise indicated
>    extreme discontent? If so, please summarise the areas
>    of conflict in separate email to the Responsible Area
>    Director.

The chairs have no knowledge of any such issues.

> 7. Have the chairs verified that the document adheres to
>    all of the ID Checklist items ?

Yes, as far as humanly possible.

> 8. Is the document split into normative and informative
>    references? Are there normative references to IDs,
>    where the IDs are not also ready for advancement or
>    are otherwise in an unclear state? (note here that the
>    RFC editor will not publish an RFC with normative
>    references to IDs, it will delay publication until all
>    such IDs are also ready for publication as RFCs.)

The split is good.

There are normative references to the following I-Ds that are believed to be
ahead of this I-D in the process and will complete RFC publication before
this I-D:

There is one normative down-reference. It is believed that the referenced
RFC is in the process of being upgraded to standards track.

RFC 3784 Intermediate System to Intermediate System (IS-IS)
                  Extensions for Traffic Engineering (TE)

There is also a normative reference to the ISIS specification. It is
believed that this is also acceptable.

> 9. What is the intended status of the document? (e.g.,
>    Proposed Standard, Informational?)

Proposed Standard

> 10. For Standards Track and BCP documents, the IESG
>     approval announcement includes a write-up section
>     with the following sections:
>
> a. Technical Summary
>    The relevant information for the technical summary can
>    frequently be found in the abstract and/or
>    introduction of the document. If not, this may be an
>    indication that there are deficiencies in the abstract
>    or introduction.

It is highly desirable to take into account Traffic Engineering (TE) node
capabilities during Multi Protocol Label Switching (MPLS) and Generalized
MPLS (GMPLS) Traffic Engineered Label Switched Path (TE-LSP) route
selection. For instance, the capability of a Label Switching Router (LSR) to
act as a branch of a Point-To-MultiPoint (P2MP) LSP influences the choice of
LSRs on the route of a P2MP LSP.

This document specifies extensions to the Open Shortest Path First (OSPF)
and Intermediate System-Intermediate System (IS-IS) traffic engineering
extensions for the advertisement of control plane and data plane traffic
engineering node capabilities.

> b. Working Group Summary
>    Was there anything in WG process that is worth noting?
>    For example, was there controversy about particular
>    points, decisions where consensus was particularly
>    rough, etc.

Nothing special. The ISIS working group had some comments about the use of
ISIS terminology that were fixed.

> c. Protocol Quality
>    Are there existing implementations of the protocol?

Two implementations known.

>    Have a significant number of vendors indicated they
>    plan to implement the specification?

No significant discussions on this point, but various vendors have indicated
that they intend to implement some of the features (mixed MPLS and GMPLS
control plane, P2MP MPLS-TE) that will depend on this function.

>    Are there any reviewers that merit special mention as
>    having done a thorough review (i.e., that resulted in
>    important changes or a conclusion that the document
>    had no substantive issues)?

The Acknowledgements section of the I-D recognises Benoit Fondeviole, Adrian
Farrel, Dimitri Papadimitriou, Acee Lindem and David Ward for their useful
comments and suggestions.