RSVP-TE Signaling Extension for LSP Handover from the Management Plane to the Control Plane in a GMPLS-Enabled Transport Network
draft-ietf-ccamp-pc-spc-rsvpte-ext-07

Dan Li wrote an email to Ben Campbell that seems to address his major concern from his GenArt review. (The email is copied below). This needs to be worked up into explanatory text. Ben's other minor points also need to be considered.

> Thank you for reviewing our draft and for your valuable comments. 
> I think that your question arises from the two components of the 
> process that are required in order to move an LSP between the 
> management plane and the control plane.
> 
> The first component of the process depends on the normal GMPLS 
> signaling messages and the use of the H-bit that this draft 
> defines to be carried in the ADMIN-STATUS object.  That component
> of the process is invariant. It must always be used to conform to
> this document.
> 
> The second component of the process is the information that needs
> to be available at each node along the LSP to ensure that the 
> transition is carried out correctly. There are two possible
> situations (assuming we are moving from management plane to
> control plane):
> 
> 1. The management plane knows the full path of the LSP (i.e. all
> of the nodes, links, component links, and labels/resources for the 
> whole end-to-end path). This may be the case in some management 
> systems that have carefully tracked and correlated the LSP as it
> was manually provisioned, and in this case the full information 
> can be provided to the head-end LSR to be encoded in an Explicit
> Route Object and signaled using the messages and procedures in the 
> first component process mentioned above.
> 
> 2. The management plane does not have access to all of the path 
> information, or is unable to provide it to the head-end LSR for
> some reason. This situation might happen for many reasons, but 
> consider for example a centralized management system that can see
> and collect the information, but an operator that wishes to
> manually request that the transition is made by entering a 
> command at the head-end LSR - it would not be sensible to ask
> them to type in all of the path information (very error prone).
> 
> The two situations of the second component use exactly the same 
> messages and objects (described for the first component), and 
> only differ in how much information is placed in the ERO on the
> Path message. In the first case, the full information is present
> and directs the behavior at each node - the state in the data
> plane is cross-checked against the information in the message.
> In the second case, less or no information is placed in the ERO
> and each node must inspect the data plane state to work out
> exactly what it must do and what information it must pass to the
> next hop.
> 
> Please note that there are many similarities here with the way
> that LSPs can be set up using the control plane. It is possible
> to supply a full and detailed ERO that explicitly controls
> exactly what is done at every hop of the path. But it is also
> possible to use a "loose ERO" or no ERO at all so that the 
> routing and label/resource allocation decisions are made hop-by-
> hop. These choices have existed in RSVP-TE from day one (RFC 3209)
> and exist to give the operator the choice about how to run their 
> network, and how much management control to exert.
> 
> I hope this explains that the two alternative approaches are not
> really different "competing" solutions, but are just different
> aspects of the same solution.