[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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.