Exclude Routes - Extension to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)
draft-ietf-ccamp-rsvp-te-exclude-route-06

[Ballot comment]
Section 2., paragraph 0:
>    2. Each subobject MUST be consistent. If a subobject is not con-
>      sistent then the node SHOULD return a PathErr with error code
>      "Routing Problem" and error value "Inconsistent Subobject".

  Where is consistency defined?


Section 2., paragraph 0:
>    2. The EXRS MAY be supported. If supported, the same restrictions
>      as for the XRO apply.

  Text before the list says "implementation MUST be at least compliant
  with the following", but this is a MAY.

[Ballot comment]
Typographical errors noted in the SecDir Review by Angelos Keromytis:
    - in Section 4.2: "inlcuded"
    - in Section 5: "some elements appears"
    - in A.1: "con-  figured", "A1- strict" (spurious whitespace)

Proto writeup by Deborah Brungard (co-chair):

draft-ietf-ccamp-rsvp-te-exclude-route-06.txt

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

Yes.

Note that Adrian is co-author.

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

No concerns.

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

I think everything necessary is already done.

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

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

WG agrees.

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

No.

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

The chairs have done their best.

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

Split is OK

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

Proposed Standard.

> For Standards Track and BCP documents, the IESG approval announcement
> includes a write-up section with the following sections:
> Technical Summary:

The RSVP-TE specification, "RSVP-TE: Extensions to RSVP for LSP Tunnels" (RFC 3209) and GMPLS extensions to RSVP-TE, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions" (RFC 3473) allow abstract nodes and resources to be explicitly included in a path setup, but not to be explicitly excluded.

In some networks where precise explicit paths are not computed at the head end it may be useful to specify and signal abstract nodes and resources that are to be explicitly excluded from routes. These exclusions may apply to the whole path, or to parts of a path between two abstract nodes specified in an explicit path. How Shared Risk Link Groups (SLRGs) can be excluded is also specified in this document.

This document specifies ways to communicate route exclusions during path setup using RSVP-TE.

> Working Group Summary

The working group had consensus on this document.

> Protocol Quality

This document has been implemented.

IANA Last Call Comment:

First action:
Upon approval of this document, the IANA will make the following assignments in the "RSVP PARAMETERS" registry located at
http://www.iana.org/assignments/rsvp-parameters
RSVP PARAMETERS
First assignment:
[TDB-232] EXCLUDE_ROUTE
Defined CType: 1 (Exclude Route)

Sub-objects
Type Subobject
-------------+-------------------------------
1 IPv4 prefix [RFC3209,RFC-ccamp-rsvp-te-exclude-route]
2 IPv6 prefix [RFC3209,RFC-ccamp-rsvp-te-exclude-route]
4 Unnumbered Interface ID [RFC3209,RFC-ccamp-rsvp-te-
exclude-route]
32 Autonomous system number [RFC3209,RFC-ccamp-rsvp-te-
exclude-route]
TBD-35 SRLG [RFC-ccamp-rsvp-te-exclude-route]
TBD-33 ERO [RFC-ccamp-rsvp-te-exclude-route]
TBD-34 ERO and XRO [RFC-ccamp-rsvp-te-exclude-route]


Second action:
Upon approval of this document, the IANA will make the following assignments in the "RSVP PARAMETERS" registry located at
http://www.iana.org/assignments/rsvp-parameters
table "Error Codes and Globally-Defined Error Value Sub-Codes"

Error Code Meaning
TBD-64 Unsupported Exclude Route Subobject Type [RFC-ccamp-rsvp-te-exclude-route]
TBD-65 Inconsistent Subobject [RFC-ccamp-rsvp-te-exclude-
route]
TBD-66 Local Node in Exclude Route [RFC-ccamp-rsvp-te-exclude-
route]
TBD-67 Route Blocked by Exclude Route [RFC-ccamp-rsvp-te-exclude-
route]

We understand the above to be the only IANA Actions for this document.