IGP Routing Protocol Extensions for Discovery of Traffic Engineering Node Capabilities
draft-ietf-ccamp-te-node-cap-05

[Ballot discuss]
Part one: Ross, I think you are using the IESG Note field improperly. I don't want the text present in the IESG note to be included in the document.

Part two: There is missing explicit rules for how to handle the expansion of the bit-fields. To me it appear that the following is needed:
1. Strict requirement on setting the reserved bits to 0.
2. A requirement to either ignore or discard the whole description on the presence of unknown bits being set (value = 1). Ignores appears to be more suitable, but needs to be defined.
3. Clearer definition that additional bytes or words may be added to the value part if there is need for more rooms for the indication bits.

[Ballot comment]
One of the cpmments from the Gen-ART Review by Pasi Eronen has not
  been handled.  The other comments have been handled by notes to the
  RFC Editor.  Jean-Louis Le Roux indicated that the change would be
  made:
  >
  > So we will remove the sentence "[IS-IS-CAP] defines a
  > new code point registry for sub-TLVs carried in the ISIS
  > CAPABILITY TLV" and replace by "IANA has defined a registry
  > for sub-TLVs of the IS-IS CAPABILITY TLV"

[Ballot discuss]
One of the cpmments from the Gen-ART Review by Pasi Eronen has not
  been handled.  The other comments have been handled by notes to the
  RFC Editor.  Jean-Louis Le Roux indicated that the change would be
  made:
  >
  > So we will remove the sentence "[IS-IS-CAP] defines a
  > new code point registry for sub-TLVs carried in the ISIS
  > CAPABILITY TLV" and replace by "IANA has defined a registry
  > for sub-TLVs of the IS-IS CAPABILITY TLV"

IANA Last Call Comments:

This document is the same as the 1st Last Call.

However, the author mentioned about the Action 3
as follows.

As regards action #3, bit numbers should be
decremented so as to start from 0, we made a
mistake in the draft, this will be corrected.

We should have:

Bit No. Name Reference
--------+---------------------------------------+-----------

0 B bit: P2MP Branch LSR capability | [RFC-ccamp-te-node-cap-05]
1 E bit: P2MP Bud LSR capability | [RFC-ccamp-te-node-cap-05]
2 M bit: MPLS-TE support | [RFC-ccamp-te-node-cap-05]
3 G bit: GMPLS support | [RFC-ccamp-te-node-cap-05]
4 P bit: P2MP RSVP-TE support | [RFC-ccamp-te-node-cap-05]
5-7 Available for assignment | [RFC-ccamp-te-node-cap-05]

Please update the document, or put some note for this
correction.

IANA Last Call Comments:


Action #1:
Upon approval of this document, the IANA will make
the following changes in "OSPFv2 Parameters" registry
located at

http://www.iana.org/assignments/ospfv2-parameters

sub-registry "OSPF Router Information (RI) TLVs - per [RFC-ietf-ospf-cap-10.txt]"


TDB | TE Node Capability Descriptor | [RFC-ccamp-te-node-cap-05]


Action #2:
Upon approval of this document, the IANA will make
the following
assignement in "IS-IS TLV Codepoints per [RFC3563]"
registry located at

http://www.iana.org/assignments/isis-tlv-codepoints

sub-registry "Sub-TLVs for TLV 242 "

1 | TE Node Capability Descriptor | [RFC-ccamp-te-node-cap-05]



Action #3:
Upon approval of this document, the IANA will create
the following registry "Link State Routing TE Capability"
located at

http://www.iana.org/assignments/TBD

Initial contents of this registry will be:


Allocation policy "IETF Consensus"

Bit No. Name Reference
--------+---------------------------------------+-----------
0 Available for assignment | [RFC-ccamp-te-node-cap-05]
1 B bit: P2MP Branch LSR capability | [RFC-ccamp-te-node-cap-05]
2 E bit: P2MP Bud LSR capability | [RFC-ccamp-te-node-cap-05]
3 M bit: MPLS-TE support | [RFC-ccamp-te-node-cap-05]
4 G bit: GMPLS support | [RFC-ccamp-te-node-cap-05]
5 P bit: P2MP RSVP-TE support | [RFC-ccamp-te-node-cap-05]
6-7 Available for assignment | [RFC-ccamp-te-node-cap-05]

Note: this registry covers both ISIS and OSPF

Proto writeup by Adrian Farrel:

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.

PROTO Write-up

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