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

[Ballot comment]
Cleared my DISCUSS, since Russ and Tim have ben raising the same issue.

Document has idnits issues that should have been fixed before this reached the IESG.

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot discuss]
(1) Section 4.2.1.2 and 4.2.2.2 specify "the handover procedure is aborted as described in
Section 4.1", but I could not resolve the reference.  Perhaps the reference should be to 4.2.1.1?

(2) Section 5 specifies an alternative procedure for MP to CP handover.  The method in section 4
is referred to as the "primary" method, but section 5 indicates "both methods are required."
Does this mean both are mandatory to implement?  If so, what makes the other method
"primary"?

[Ballot discuss]
The Gen-ART Review by Ben Campbell on 1 Feb 2010 raised one major
  concern.  Ben asks:

    This draft defines two different procedures for accomplishing the
    same goal. While it describes them as primary and alternative, it
    is not clear to me if an implementation is expected to implement
    both of them, or whether they are intended to interoperate. It
    would also be helpful to have some guidance on when one might
    choose one over the other.

  While addressing Ben's major concern, please consider the minor
  concerns that he raised as well.

[Ballot discuss]
Section 5., paragraph 1:
>    An alternative way of getting the LSP related information required
>    for the MP to CP handover is also defined in this draft.  The
>    rationale behind this way is that only a minimal set of information
>    is handed over from MP to CP at LSPs Ingress node.  Instead of
>    collecting within MP all the LSP relevant information down to the
>    Label level, formatting it to an ERO and passing it to CP, as in
>    previously described solution, it is possible to start with a minimum
>    amount of information.  The full ERO method and the partial/no ERO
>    one do not exclude each other; both methods are required.

  DISCUSS: I have one question that I'd like to discuss on the call or
  before via email. I fully expect to clear immediately afterwards. If I
  understand this correctly, Section 5 describes an alternative
  procedure for what is described in Sections 4.1 and/or Section 4.2,
  and that both alternatives are REQUIRED to implement. What is the
  benefit of this added complexity? I'm not an RSVP-TE expert and maybe
  this is obvious if one is, but it doesn't seem worth the complexity to
  allow two variants of the same operation that don't seem to have a
  very different set of tradeoffs.

IANA comments/questions:

QUESTION: Can you confirm that these actions are correct? The
document wasn't clear.

Action #1:

Upon approval of this document, IANA will make the following
assignment in the "Administrative Status Information Flags" registry at
http://www.iana.org/assignments/gmpls-sig-parameters

Bit Number Hex Value Name Reference
---------- ----------- ------------------------------------ ---------
25 0x00000040 Handover (H) [RFC-ccamp-pc-spc-rsvpte-ext-06]


Action #2:

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

TBD (35, if available) Handover failure [RFC-ccamp-pc-spc-rsvpte-ext-06]

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

1 = Cross-connection mismatch
2 = Other failure


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

Proto-write-up for: draft-ietf-ccamp-pc-spc-rsvpte-ext-04
Intended status: Proposed Standard

>(1.a) Who is the Document Shepherd for this document? Has the
> Document Shepherd personally reviewed this version of the
> document and, in particular, does he or she believe this
> version is ready for forwarding to the IESG for publication?

Lou Berger is the Document Shepherd.

He has reviewed the document and believe this version is ready for
publication at the intended status.

>(1.b) Has the document had adequate review both from key WG members
> and from key non-WG members? Does the Document Shepherd have
> any concerns about the depth or breadth of the reviews that
> have been performed?

The document has received adequate review and discussion. It has been
revised to be consistent with WG opinion and other related activities in
the IETF.

>(1.c) Does the Document Shepherd have concerns that the document
> needs more review from a particular or broader perspective,
> e.g., security, operational complexity, someone familiar with
> AAA, internationalization, or XML?

No.

>(1.d) Does the Document Shepherd have any specific concerns or
> issues with this document that the Responsible Area Director
> and/or the IESG should be aware of?

No.

> For example, perhaps he
> or she is uncomfortable with certain parts of the document, or
> has concerns whether there really is a need for it. In any
> event, if the WG has discussed those issues and has indicated
> that it still wishes to advance the document, detail those
> concerns here. Has an IPR disclosure related to this document
> been filed? If so, please include a reference to the
> disclosure and summarize the WG discussion and conclusion on
> this issue.

No IPR disclosures were found.

>(1.e) 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?

Consensus appears to be good.

>(1.f) Has anyone threatened an appeal or otherwise indicated extreme
> discontent? If so, please summarize the areas of conflict in
> separate email messages to the Responsible Area Director. (It
> should be in a separate email because this questionnaire is
> entered into the ID Tracker.)

No threats. No discontent.

>(1.g) Has the Document Shepherd personally verified that the
> document satisfies all ID nits? (See
> http://www.ietf.org/ID-Checklist.html and
> http://tools.ietf.org/tools/idnits/.) Boilerplate checks are
> not enough; this check needs to be thorough. Has the document
> met all formal review criteria it needs to, such as the MIB
> Doctor, media type, and URI type reviews? If the document
> does not already indicate its intended status at the top of
> the first page, please indicate the intended status here.

Yes

>(1.h) Has the document split its references into normative and
> informative?

Yes.

> Are there normative references to documents that
> are not ready for advancement or are otherwise in an unclear
> state?

No.

> If such normative references exist, what is the
> strategy for their completion?

N/A.

> Are there normative references
> that are downward references, as described in [RFC3967]? If
> so, list these downward references to support the Area
> Director in the Last Call procedure for them [RFC3967].

No downward references.

>
>(1.i) Has the Document Shepherd verified that the document's IANA
> Considerations section exists and is consistent with the body
> of the document? If the document specifies protocol
> extensions, are reservations requested in appropriate IANA
> registries? Are the IANA registries clearly identified? If
> the document creates a new registry, does it define the
> proposed initial contents of the registry and an allocation
> procedure for future registrations? Does it suggest a
> reasonable name for the new registry? See [RFC2434]. If the
> document describes an Expert Review process, has the Document
> Shepherd conferred with the Responsible Area Director so that
> the IESG can appoint the needed Expert during IESG Evaluation?

The IANA section looks.

>(1.j) Has the Document Shepherd verified that sections of the
> document that are written in a formal language, such as XML
> code, BNF rules, MIB definitions, etc., validate correctly in
> an automated checker?

Yes, no automated checks needed.

>(1.k) The IESG approval announcement includes a Document
> Announcement Write-Up. Please provide such a Document
> Announcement Write-Up. Recent examples can be found in the
> "Action" announcements for approved documents. The approval
> announcement contains the following sections:
>
> Technical Summary
> Relevant content 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.

This memo describes an extension to Generalized Multi-Protocol
Label Switching signaling that enables the transfer of connection
ownership between the Management and the Control Planes. Such a
transfer is referred to as a Handover. This document defines all
Handover related procedures. This includes the handling of failure
conditions and subsequent rversion to original state. A basic
premise of the extension is that the handover procedures must never
impact an already established data plane.

> Working Group Summary
> Was there anything in the WG process that is worth noting?
> For example, was there controversy about particular points
> or were there decisions where the consensus was
> particularly rough?

This document received adequate attention and discussion in its early
revisions. The document has been laregly stable for quite some time,
mainly needing revisions as part of the publication process.

> Document Quality
> Are there existing implementations of the protocol? Have a
> significant number of vendors indicated their plan to
> implement the specification? Are there any reviewers that
> merit special mention as having done a thorough review,
> e.g., one that resulted in important changes or a
> conclusion that the document had no substantive issues? If
> there was a MIB Doctor, Media Type, or other Expert Review,
> what was its course (briefly)? In the case of a Media Type
> Review, on what date was the request posted?
>

There have been no public statements related to intent to implement, but
it is expected that some/all of the primary Authors plan to implement.

> Personnel
> Who is the Document Shepherd for this document?

Lou Berger.
> Who is the
> Responsible Area Director?

Adrian Farrel

> If the document requires IANA
> experts(s), insert 'The IANA Expert(s) for the registries
> in this document are .'
>