Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions in Support of Calls
draft-ietf-ccamp-gmpls-rsvp-te-call-04

[Ballot discuss]
[This discuss does actually have its roots in my previous discuss.  I realize it is not obvious.  There have been a lot of side discussions]

One use case of the call concept raises security concerns.  In
particular, calls are being proposed so that you can authenticate to a
call server using an end-to-end notify, get some policy goop and that
goop can be used for policy decisions like whether to accept your
call.  The problem is that this creates a situation where new security
associtaions are required that for the most part typically do not come
up in RSVP today even though end-to-end notify is already supported.
That triggers RFC 4107 analysis and a very high probability that
mandatory automated key management is required.  We don't want to
block this document on that.


I propose the following:

old:
  Note, additionally, that the process of independent Call
  establishment, where the Call is set up separately from the LSPs, may
  be used to apply an extra level of authentication and policy for the
  end-to-end LSPs above that which is available with Call-less,
  hop-by-hop LSP setup.

new: Note, additionally, that it would be desirable to use the process
  of independent Call establishment, where the Call is set up
  separately from the LSPs, to apply an extra level of authentication
  and policy for the end-to-end LSPs above that which is available
  with Call-less, hop-by-hop LSP setup.  However doing so will
  require additional work to set up security associations between the
  peer and the call manager that meet the requirements of RFC 4107.
  The mechanism described in this document is expected to meet this
  use case when combined with this additional work.  Application of
  this mechanism to the authentication and policy use case prior to
  standardization of a security solution is inappropriate and outside
  the current applicability of the mechanism.

[Ballot comment]
I found this document very difficult to follow.  Side conversations with Adrian and Ross convince me that the issues I was concerned about are due to terminology confusion rather than errors in the document.  But I remain very concerned that we are putting out a document where the set of terms overlaps those used in other IETF communities in ways that hinder communication.  Given that there exist discusses on this document that may require changes, I hope that the chairs and authors can work on alternatives with input from a broader community.

[Ballot comment]
5.3 LINK_CAPABILITY object
...
  The contents of the LINK_CAPABILITY object is defined as series of
  variable-length data items called subobjects. The subobject format is
  defined in [RFC3209].

  The following subobjects are currently defined.
...

Is there an IANA registry for the subobjects, which seem to be defined
in a variety of RFCs?

[Ballot discuss]
According to
http://rtg.ietf.org/~fenner/ietf/deps/index.cgi?doc=draft-ietf-ccamp-gmpls-rsvp-te-call, draft-ietf-ccamp-gmpls-rsvp-te-call has a DOWNREF to RFC4139 that wasn't
called out during IETF LC. Unless this can simply be reclassified as an
informative citation, the DOWNREF rules would need to be followed.

(Sorry for playing DOWNREF police; we do need a better process for this.)

[Ballot discuss]
This specification combined with RFC 4139 does not clearly explain
what calls do and it is not obvious how calls meet the requirements of
RFC 4139.  As far as I can tell by reading this spec, a call is a way
of optionally transmitting link capability information from one node
to another before establishing a connection.  It also groups
connections together.  However no normative behavior changes are
described for connections in a call vs those not in a call.  For
reporting and other things that do not affect interoperability,
leaving that as an implementation matter may be appropriate.
But let's consider one of the requirements from RFC 4139:

  -  An upgrade strategy for control plane operations, where a call
      control component (service provisioning) may be separate from the
      actual nodes hosting the connections (where the connection control
      component may reside).












Since there are no normative changes to how connections are
established (other than carrying the short call ID) I don't see how
this requirement is met.


I'm concerned that the call concept may not be specified in enough
detail that implementations can interoperably choose when to use calls
and that implementations will actually meet the requirements of RFC
4139.  I'm also concerned that reviewers may not understand the call
concept well enough to review the architecture and security.

This discuss sounds really big.  However it may well be a paragraph or
so will make it all click and then I will understand.

IANA Update Comments:

Following actions have been revised #1, #2, #3 as requested
by editor Open question on #4:
The document seems to update the Notify Message, IANA judged
that in order to implement Notify correctly implemntor should
read both RFC3473 AND this document, thus the reference addition.
If this is incorrect please advise and we will remove the action.


--- start of actions---

First action:
Upon approval of this document, the IANA will make the
following assignments in the "RSVP" registry located at
http://www.iana.org/assignments/rsvp-parameters in
sub-registry "Class Names, Class Numbers, and Class Types"

TBD-132 LINK_CAPABILITY [RFC-ccamp-gmpls-rsvp-te-call-01.txt]

Class Types or C-Types:
1 Type 1 TE Link capabilities [RFC-ccamp-gmpls-rsvp-te-call-01.txt]



----

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

TDB-32 Call Management [RFC-ccamp-gmpls-rsvp-te-call-01.txt]

This Error Code has the following globally-defined Error
Value sub-codes:

TDB-1 Call Management/Call ID Contention [RFC-ccamp-gmpls-
rsvp-te-call-01.txt]
TDB-2 Call Management/Connections still Exist [RFC-ccamp-
gmpls-rsvp-te-call-01.txt]
TDB-3 Call Management/Unknown Call ID [RFC-ccamp-gmpls-
rsvp-te-call-01.txt]
TDB-4 Call Management/Duplicate Call [RFC-ccamp-gmpls-
rsvp-te-call-01.txt]



---
Third action:
Upon approval of this document, the IANA will make the
following assignments in the "GMPLS Signaling Parameters"
registry located at

http://www.iana.org/assignments/gmpls-sig-parameters
in sub-registry: "Administrative Status Information Flags"

0x00000008 Call control (C) [RFC-ccamp-gmpls-recovery-e2e-signaling-04.txt]


---
Forth action:
Upon approval of this document, the IANA will make the
following assignments in the "RSVP" registry located at
http://www.iana.org/assignments/rsvp-parameters
in sub-registry "Message Types"

OLD:
21 = Notify Message [RFC3473]

NEW:
21 = Notify Message [RFC3473, RFC-ccamp-gmpls-rsvp-te-
call-01.txt]


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

[Ballot comment]
The document references some out-of-date IPsec documents.  Please
  refer to RFC 4302 instead of RFC 2402, and refer to RFC 4303
  instead of RFC 2406.

PROTO Write-up by Adrian Farrel

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 and yes.
Adrian is a co-author.
Deborah did a thorough review at WG last call.


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?
"Somewhat adequate."
This is not a topic that is of fundamental interest to some
people in the WG (see item 5) so review has not been as
deep as it might have been.
Nevertheless, the key members of the WG have taken the time
to review the draft.


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 would be interested to hear the views of the Security Directorate. I do not believe that there is any fundamental
change in the operational nature of RSVP-TE security, and I
think that the Call mechanism brings new security capabilities to GMPLS, but I would welcome their input. [Editor's/AD note: There has been a security directorate review and the document has been updated in response.]


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?
I would say that it is understood widely, but that the need
is not seen strongly across the whole WG. However, as various items start to be considered by the WG (e.g. GMPLS
support for VCAT, GMPLS control of MS-SPRing, etc.) we find that this mechanism is being turned to. Thus the support is growing.


In addition, this mechanism provides a fundamental building
block for support of ASON calls using GMPLS signaling, and
this is a soft commitment from the CCAMP working group to
the ITU-T. A subsequent I-D will describe the applicability
of GMPLS Call signaling to the ASON environment.


The final stages of review of this document included some
strong debate about the precise mechanisms used to provide
this functionality. These issues were raised predominately
by participants in the ITU-T. I believe that technical resolution was reached on all points.


An issue was repeatedly raised about the processing on
legacy nodes that are also non-conformant to existing RFCs.
This point was also raised during GenArt review. We added text to cover this case explicitly and are comfortable that
the process will be resilient to this type of situation.


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


7. Have the chairs verified that the document adheres to  all of the ID Checklist items ?
Within the bounds or our human fallibilities, yes.


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.)
References are good.


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




For Standards Track and BCP documents, the IESG approval
announcement includes a write-up section with the following
sections:
Technical Summary
  In certain networking topologies, it may be advantageous
  to maintain associations between endpoints and key  transit points to support an instance of a service. Such
  associations are known as Calls.


  A Call does not provide the actual connectivity for
  transmitting user traffic, but only builds a
  relationship by which subsequent Connections may be  made. In Generalized MPLS (GMPLS) such Connections are  known as Label Switched Paths (LSPs).


  This document specifies how GMPLS RSVP-TE signaling may
  be used and extended to support Calls by utilizing the
  pre-existing Notify message. These mechanisms provide  full and logical Call/Connection separation.


  The mechanisms proposed in this document are applicable
  to any environment (including multi-area), and for any  type of interface: packet, layer-2, time-division  multiplexed, lambda, or fiber switching.


Working Group Summary
  An issue was repeatedly raised about the processing
  on legacy nodes that are also non-conformant to existing
  RFCs. This point was also raised during GenArt review.
  We added text to cover this case explicitly and are
  comfortable that the process will be resilient to this
  type of situation.
 
Protocol Quality
  There is at least one known implementation of this
  protocol extension.


  Several I-Ds currently being examined by CCAMP propose
  to make use of this extension, and that will give rise
  to significant numbers of implementations.

IANA Last Call Comment:

** Note that IANA has a question about Second Action. **

First action:
Upon approval of this document, the IANA will make the
following assignments in the "RSVP" registry located at

http://www.iana.org/assignments/rsvp-parameters
in sub-registry "Class Names, Class Numbers, and Class Types"

Class-Num = TBD-132 (form 10bbbbbb)
Class Types or C-Types:
C-Type = 1 (TE Link Capabilities) [RFC-ccamp-gmpls-rsvp-te-call-01.txt]


----
Second action:
Upon approval of this document, the IANA will make the
following assignments in the "RSVP" registry located at

http://www.iana.org/assignments/rsvp-parameters
in sub-registry "Error Codes and Globally-Defined Error
Value Sub-Codes"

TDB-32 Call Management [RFC-ccamp-gmpls-rsvp-te-call-01.txt]
TDB-1 Call Management/Call ID Contention
TDB-2 Call Management/Connections still Exist
TDB-3 Call Management/Unknown Call ID
TDB-4 Call Management/Duplicate Call

Question to editors: IANA assumes that registration in the 3-23
range is not requestested. Please advise this is correct.

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

The action requested is to add a bit to a sub-sub-registry
that is  requested in TIX:25409
Doc:draft-ietf-ccamp-gmpls-recovery-e2e-signaling-04.txt

The action here is to update the reference for the C bit.

---
Forth action:
Upon approval of this document, the IANA will make the
following assignments in the "RSVP" registry located at

http://www.iana.org/assignments/rsvp-parameters
in sub-registry "Message Types"
OLD:
21 = Notify Message [RFC3473]

NEW:
21 = Notify Message [RFC3473, RFC-ccamp-gmpls-rsvp-te-
call-01.txt]


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