Subject: Document Action: 'Reoptimization of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) loosely routed Label Switch Path (LSP)' to Informational RFC

From: The IESG <[email-masked]>
Date: Mon, 01 May 2006 17:46:28 -0400

The IESG has approved the following document:

- 'Reoptimization of Multiprotocol Label Switching (MPLS) Traffic Engineering 
   (TE) loosely routed Label Switch Path (LSP) '
   <draft-ietf-ccamp-loose-path-reopt-02.txt> as an Informational RFC

This document is the product of the Common Control and Measurement Plane 
Working Group. 

The IESG contact persons are Ross Callon and Bill Fenner.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-loose-path-reopt-02.txt

Technical Summary
 
   This document defines a mechanism for the reoptimization of loosely
   routed MPLS and GMPLS (Generalized Multiprotocol Label Switching)
   Traffic Engineering (TE) LSPs signaled with RSVP-TE.
 
Working Group Summary
 
   As far as I know there was no dissent. I am concerned that the 
   document might not have had as many people seriously interested in
   it as might be optimal to make sure that all options are considered
   in detail. 
 
Protocol Quality
 
   This has been approved as "informational".  

   There are very minor editorial sub-optimal use of English words. 
   For example, at the beginning of section 3: "The aim of this section
   is purely to remind the mechanisms involved in...". Here the word 
   "remind" should be "summarize". There are only a small number of these, 
   and thus they can be corrected by the RFC editor prior to publication. 

Note to RFC Editor
 
There are a few minor nits to be corrected prior to publication:

nit1>> The first paragraph of section 3 current says: 

    The aim of this section is purely to remind the mechanisms
    involved in the establishment of a loosely routed TE LSP (in
    line with [RFC3209]) and does not introduce any new protocol
    extensions or mechanisms.

This should be corrected to say:

    The aim of this section is purely to summarize the mechanisms
    involved in the establishment of a loosely routed TE LSP, as
    specified in [RFC3209]. The reader should see RFC3209 for a
    more detailed description of these mechanisms.

nit2>>In the first paragraph of section 4, there is a sentence that says:

    Since a preferable (e.g. shorter) path might not be visible from the 
    head-end LSR by means  of the IGP if the head-end LSR does not belong
    to the head-end IGP area...".

This should say: 

    Since a preferable (e.g. shorter) path might not be visible from the 
    head-end LSR by means of the IGP if the head-end LSR does not belong
    to the same IGP area where the associated topology change occurred...".

nit3>> in section 7 there is the sentence:

    Such a procedure would not be in conflict with any mechanisms
    not already documented in [RFC3209] and [RFC3473].

this should say: 

    Such a procedure would not be in conflict with any mechanisms
    already documented in [RFC3209] and [RFC3473].

In addition, the following changes should be made to the IANA
Considerations section:

REMOVE:
   IANA will assign a new flag named "Path re-evaluation request" in the
   SESSION-ATTRIBUTE object (C-Type 1 and 7) specified in [RFC3209].
   Suggested value is (to be confirmed by IANA) 0x20.

Change:
OLD:
   IANA will also assign three new error sub-code values for the RSVP

NEW:
   IANA will assign three new error sub-code values for the RSVP

And in Section 5.1 change:

OLD:
   The following new flag of the SESSION_ATTRIBUTE object (C-Type 1 and
   7) is defined (suggested value to be confirmed by IANA):

NEW:
   The following new flag of the SESSION_ATTRIBUTE object (C-Type 1 and
   7) is defined:

IANA Note

   The SESSION ATTRIBUTE flag request has been removed via RFC Editor
   note, as that registry has not yet been created.  The assignments for
   the RSVP PErr error subcodes are still requested.  A document will
   follow to create the SESSION ATTRIBUTE flag registry.