Subject: Review of draft-caviglia-mp2cpcp2mp-01.txt

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 4 Jun 2005 13:28:37 +0100

Hi Diego,

I have had a look through your I-D and have a few comments attached.

This could be a nice and useful little function requiring only a very
short document and just one bit on the wire. Excellent!

Wrt your proposed solution, I think it is nearly there, but needs a few
tweaks and there are still a couple of areas to complete.

You also really need to do some work on the English. I known this is hard
(you write better English than I write Italian!), but in order that the
document can be properly reviewed (and hopefully implemented one day) we
have to improve the use of language. What I suggest is that you make the
revisions necessary for the next version and then you get someone to
review the document just to polish the language. I'm sure there would be
volunteers to work with you on this.

Regards,
Adrian

===========

Network Working Group                                     Diego Caviglia
IETF Internet Draft                                              Marconi
Proposed Status: Informational

## Why do you propose this as Informational? Do you not want it to be
## standardized?
## you may even want to flag it as "Updates RFC 3473"

Expires: August 2005                                       Dino Bramanti
                                                                 Marconi

                                                           Nicola Ciulli
                                                               Nextworks

                                                           February 2005

        GRSVP-TE signaling extension for LSP ownership handover from
             Management Plane to Control Plane and vice versa.

## I would prefer the title to be...
## GMPLS Signaling Extensions for the Transfer of Ownership of Label
## Switched Paths Between the Management and Control Planes

                     draft-caviglia-mp2cpcp2mp-01.txt

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of Section 3 of RFC 3667. By submitting this Internet-Draft, each
   author represents that any applicable patent or other IPR claims of
   which he or she is aware have been or will be disclosed, and any of
   which he or she become aware will be disclosed, in accordance with
   RFC 3668.
## You'll need to fix this boilerplate before you republish.
## Don't forget to run the idnis script found at
## http://ietf.levkowetz.com/tools/idnits/

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Copyright Notice

   Copyright (C) The Internet Society (2005). All Rights Reserved.

Abstract

   This memo introduces a new flag in the Administrative Status object,
   namely the "Handover" flag, and defines its use within GRSVP-TE
   signaling.  This flag SHOULD be used in order to allow LSPs,
   originally created and controlled by the Management Plane (MP), to be
   transferred to Control Plane (CP) domain and vice-versa. The result

Caviglia et al.           Expires - August 2005               [Page 1]

draft-caviglia-mp2cpcp2mp-02                            February 2005

   of the Handover flag use in GRSVP-TE is that, at the end of the
   setup signaling flow, an LSP that was created thru Management Plane
   operations is moved under Control Plane domain and control.
   Conversely, at the end of a deletion procedure, the LSP that was
   under the Control Plane domain is moved back to the Management Plane
   domain.
   Both the above procedure are not traffic affecting and can be
   performed with "in service traffic".

## It is normal for the Abstract to talk about the problem and the desired
## function rather than solutions.
##
## So you should rephrase this along the lines of...
##
## During migration scenarios it may be desirable to transfer the
## ownership of a Label Switched Path (LSP) from the Management Plane
## to the Control Plane, or vice versa. If the LSP is carrying traffic
## this change needs to be made "in service," that is, without affecting
## traffic.
##
## This memo provides minor extensions to the Generalized Multiprotocol
## label Switching (GMPLS) signaling protocol to enable this transfer of
## ownership, and descirbes the necessary procedures.

Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC-2119 [2].

Table of Contents

   1. Introduction.....................................................2
   2. LSP Adoption/Release.............................................4
      2.1 Overview.....................................................4
      2.2 LSP Adoption phase: association of GMPLS information to a MP
          born LSP - LSP SetUp.........................................4
        2.2.1 Association Procedure....................................5
        2.2.2 Association Failure Handling.............................6
      2.3 LSP Release phase- disassociation of GMPLS information to a
          MP born, CP adopted LSP - LSP Tear Down......................7
   3. RSVP Message Formats.............................................7
      3.1 Object Modification..........................................7
        3.1.1 Administrative Status Object.............................7
   4. Security Considerations..........................................8
   5. IANA Considerations..............................................8
   6. Normative References.............................................8
   7. Informational References.........................................9
   8. Acknowledgements.................................................9
   9. Author's Addresses...............................................9
   10. Intellectual Property Rights Notices............................9
   11. Full Copyright Statement.......................................10

1. Introduction

## I think that before you start you need to explain to the reader that
## when you say "LSP" you mean the data plane forwarding path and data
## plane state. There are many people who have come to use the term
## "LSP" to mean the control plane state necessary to establish and
## maintain the data plane state - of course, you do not mean this.

## You need to expand all of the acronyms the first time they are used

   The use of a GMPLS control plane over networks that are already in
   service can't be considered of course as a green field application.
   This means that in a transport network control scenario LSPs created
   and owned by Management Plane and LSPs signaled and owned by means of
   GMPLS Control Plane have to coexist. In such a situation it is
   possible that a network operator wants to move to Control Plane an
   LSP created by and belonging to Management Plane. In a similar
   fashion, the opposite operation is also needed. In this memo let's

Caviglia et al.           Expires - August 2005               [Page 2]

draft-caviglia-mp2cpcp2mp-02                            February 2005

   call "LSP adoption" the procedure that is aimed at moving an LSP born
   in Management Plane to Control Plane. Let's call "LSP release" the
   opposite procedure aimed at moving back the LSP from Control Plane to
   Management Plane.
## In fact, it isn't a question of where the LSP was "born" or of
## "moving back". The question is, which plane 'owns' the LSP before and
## after the operation. After all, the LSP could be moved back and
## forwards many times.
##
## I would suggest that "release" is a term already applied to LSP
## teardown, so you should choose another term.

   At present there is no way for a Carrier Operator that wants to
   associate/disassociate GMPLS information to an already existent LSP.
   In particular there is no way to inject LSP information and
   visibility from Management Plane to Control Plane (and the other way
   back) by means of standard G.RSVP-TE signaling flow.
## Please don't say G.RSVP-TE. It isn't an ITU-T G-series Recommendation
:-)

## You should explain why this does not work for the transfers in both
## directions. For example:
## If you try to signal an LSP to use resources already established and
## under the control of the Management Plane you will either be rejected
## by the network devices because the resources are already in use, or
## you will establish a second, parallel LSP.
## If you try to release an LSP established by the Control Plane by
## sending teardown signaling messages, the LSP will be lost before the
## Management Plane can take over.
##
## You should also explain why make-before-break is not an acceptable
## way to handle this situation. For example, one could have two LSPs
## (one set up by the Management Plane, and one set up by the Control
## Plane) and switch data between them (in the manner of 1+1 protection)
## with no significant hit on the traffic.

   A new flag in the Administrative Status Object (RFC 3471[3] and RFC
   3473 [4]), named Handover flag, is proposed in this memo as a mean to
   make possible necessary information exchange between GMPLS enabled
   nodes, in order to implement and support the functionality introduced
   above.

   Handover flag SHOULD be used during a signaling set-up (tear down,
   when performing opposite operation) and allows the association of
   LSP-related GMPLS information (at Control Plane level) to a circuit
   originated by Management Plane actions and formerly not visible and
   "known" to Control Plane itself. Data plane flow related to such LSP
   is unaware of this transfer of control from MP to CP (and back). It
   is worth taking into account that affected LSP may already be
   carrying traffic, which hasn't to be perturbed neither during MP to
   CP LSP handover, nor during dual CP to MP control transfer.

   The procedure here described is based (in case of MP to CP LSP
   handover, for instance) on the collection of information owned by
   Management Plane and related to a LSP originated in MP. This detailed
   information about route and resources used by the LSP is passed to
   Control Plane, which gets it to signal the LSP. When signaling the CP
   adopted LSP, Handover flag is set in order to make recognizable that
   signal flow and instruct GMPLS nodes about it.
   GMPLS nodes have to handle that LSP in such a way that, at the end of
   signaling, it is a full effect Control Plane owned LSP.
   Conversely, CP to MP migration is signaled over CP by relevant
   G.RSVP-TE tear down messages with Handover flag set.
   This is in some way similar to the Restart Procedure, (Section 4.3
   RFC 3473 [4]), in the sense that the cross connection in the Data
## "cross-connection" throughout the I-D
## The connection has nothing to be cross about :-)
   Plane are already present and it is only needed relevant GMPLS
   information to be associated to it.

   The modification proposed in this document refers only to
   Administrative Status object, that is, the message flow is left
   unmodified for both set-up and deletion.

## Most of your description discusses only cross-connections. But of
## course there is more going on in terms of resource reservation and
## resource activation (e.g. turning on lasers). You need to make sure
## that your language cover this.

Caviglia et al.           Expires - August 2005               [Page 3]

draft-caviglia-mp2cpcp2mp-02                            February 2005

2. LSP Adoption/Release

2.1 Overview

   In LSP association/release procedure here introduced, GRSVP-TE
   signaling messages and flow is used as normal and the processing of
   the messages is exactly the same as usual, except for the fact that
   no operation has to be performed over Data Plane. This means that the
   cross connection, which is assumed to be physically already in place
   in Data Plane, hasn't to be actually created (set-up phase)_ nor
   deleted (deletion phase) during signaling flow used to move LSP
   control from MP to CP (or CP to MP) .
## This is a major piece of problem statement (that the data plane
## must be unchanged, and that the resources are assumed to be
## already in place). You should move it to section 1.

   Such signaling messages are
   marked and recognizable for this purpose by Handover flag setting.
   When the LSP is adopted either by CP or MP, i.e. at the end of
   signaling with Handover flag set, normal CP procedures or MP
   procedures have to take their place as usual when needed. This means
   that a LSP originated in MP, signaled in CP with Handover flag on and
   hence passed to CP, can be deleted by usual and relevant Control
   Plane signaling flows (i.e. with Handover flag not set). The same
   applies when a LSP belongs to Management Plane. In other words, after
   those LSP handover procedures have taken place, the LSP is not
   different from the other LSP owned by handover destination entity,
   and it has to be treated with usual rules of that entity.

2.2 LSP Adoption phase: association of GMPLS information to a MP born
    LSP - LSP SetUp

   In order to support the adoption of a LSP, the ERO object in the Path
   message MUST be filled with all the LSP relevant information, that
   is, down to the Label level.  That can be done by means of the object
   and procedures defined in [5].
## You need to reference RFC3209 and RFC3473 here as well.
## But I think that component link identification has become clearer
## since the rework of the bundling I-D and you may be able to reference
## that instead of [5]. Talk to Zafar Ali about that issue.

   The filling of the ERO down to the Label Level, including Component
   Link identifier when necessary, is possible as we are assuming the
   LSP already exists in the Network and the MP has all the associated
   information. Management Plane is the entity holding LSP information
   and passing it over to CP during adoption.

   Signaling set-up related to the LSP adoption contains the Handover
   flag of the Administrative State Object set.
   Upon reception of GRSVP-TE Path with Handover flagged Admin Status
   object, i.e. during signaling set-up, a node SHOULD associate LSP
   info at CP level to the existing cross connection.

   The information about the fact that a LSP adoption procedure is
   ongoing on the LSP should be maintained by the TNE until Resv Confirm
   message is received at the node. That information is needed in case
   of failures during the association set-up.

Caviglia et al.           Expires - August 2005               [Page 4]

draft-caviglia-mp2cpcp2mp-02                            February 2005

   Resv and Resv Confirm messages following Path (all with Handover flag
   set) are processed as usual and, after Resv Confirm processing, the
   LSP is completely under the CP domain.  This means that any memory
   about the fact that previously was under the MP is lost.

## Hmmm. You are assuming the use of the ResvConf message and I am not
## sure that that is a good idea. Why don't you continue to retain this
## information until the Handover flag is cleared?
##
## I think this would work well because, in any case, you need to
## discuss if and when the Handover flag is cleared. Note that
## Admin Status flags are not one-off triggers, but persistent state
## controllers.
##
## Clearing the Handover flag is important because until you have
## doen this, the LSP remains in 'handover state' (that is, it might
## appear to be in the process of being sent back to the MP as
## described in section 2.3) and so the CP will never have full control.
##
## This makes the rules for processing on an LSR very clear:
## When the handover bit is set in the Path state for an LSP, neither
## the CP nor the MP may make changes to the DP state or the associated
## resources. (You would probably want to allow an MP over-ride on this,
## but that is identical to the over-ride that the MP has on a CP-owned
## LSP in normal circumstances.)

   Failures during the Adoption of an LSP are managed as usual, except
   that TNEs receiving error messages, with Path State Removed set, do
   not delete the cross connection in the data plane but only their
   GMPLS associated information.
## Well, this ruling applies to all error cases and scenarios.
## That is, while the adoption process is under way (until the ResvConf,
## or clearing of the Handover bit) an LSR MUST NOT release any Data
## Plane state associated with the LSP even if it releases Control
## Plane state.

2.2.1 Association Procedure

## Can you please use RFC2119 terminology in the definition of
## procedures. This will help to remove any ambiguities.

   This Section covers the procedure needed to manage a LSP Adoption
   procedure, that is, a GRSVP-TE signaling set-up where Path message
   contain an Administrative Status object with the Handover flag set.

   In the following the adoption of a bidirectional LSP is taken into
   consideration. The case of unidirectional LSP can be easily derived
   from that.

   A node receiving a Path message containing an Administrative Status
   object with the Handover flag set is informed about the fact that a
   LSP adoption procedure is ongoing. The node assumes that a Data Plane
   connection related to the info carried in Path Message is already in
   place. The node SHOULD check however if there is an actual Data Plane
   cross connection between the resources indicated by the message:

   - If yes then a GRSVP-TE state is associated with the cross
      connection and relevant CP data structures of LSP are created.

   - If no, that is the resources are used in a way that is different
     from the one indicated by the Path message then:

     o a PathErr with Path State Removed flag set should be generated

     o GMPLS state information is deleted but actual cross-connection in
## Don't say "GMPLS state information." Say "GMPLS Control Plane state
## information."
       the data plane are not.

   In order to be able to cope with a failure during described
   procedure, the information about the fact that the ongoing signaling
   flow is concerning an LSP adoption is maintained by the TNE until the
   receipt of the Resv Confirm. In such a way Management Plane holds LSP
   related info until Handover flagged signaling session has
   successfully ended.

## The previous paragraph highlights that you need to describe (a little
## earlier in the document) how the handover procedure is coordinated
## between the MP and CP. Although the precise mechanisms are out of
## scope, we can assume that:
## - it is under operator or management applicaiton control
## - control requests are sent to the ingress LSR by the MP
## - the MP has some way of knowing when the CP has completed its task
##   or has failed.

   The following example illustrates the possible Adoption cases either
   successful or failed.

Caviglia et al.           Expires - August 2005               [Page 5]

draft-caviglia-mp2cpcp2mp-02                            February 2005

   The cross connection to be moved under the control plane involves
   Timeslot A and B. This means that Handover flagged signaling refers
## You say "Timeslot." Does this only apply to TDM?
   to A-B xconnection over Data Plane. The symbol <----> means that the
   two Timeslots are actually cross connected over Data Plane.

          | Data Plane| Control Plane| Management Plane| Notes
   ---------------------------------------------------------------------
   Case 1 | A<---->B  | No info yet  | LSP info present| OK for MP to CP
          |           |              |                 | LSP handover
   ---------------------------------------------------------------------
   Case 2 | A<---->C  | No info yet  | LSP info present| NOK for MP to
                                                       | CP LSP handover
   ---------------------------------------------------------------------

## Perhaps instead of "LSP info present" for the MP, you should say
## "MP expects A-B".

   Case 1:
   - LSP info in Management Plane is present and describes A-B
     connection.
   - LSP is not visible yet over Control Plane.
   - A-B connection is actually present over Data Plane.
   - GRSVP-TE state (related to involved LSP) is associated to the
     cross connection after Handover flagged signaling flow
     (Path/Resv/resvConfirm with Handover flag set).
   - No actions are taken in the Data Plane.
   - At the end LSP is completely under CP control.

   Case 2:
   - LSP info in Management Plane is present and describes A-B
     connection.
   - LSP is not visible yet over Control Plane.
   - A-B connection is not actually present over Data Plane and relevant
     resources are used within other context (A is x-connected to C).
   - GRSVP-TE state (related to involved LSP) is not associated to the
     cross connection after Handover flagged signaling flow.
   - A PathErr with Path State Removed flag set should be sent Upstream.
   - No actions are taken in the Data Plane.
   - At the end LSP stays completely under MP control as before.

2.2.2 Association Failure Handling

   When a node receives a PathErr with Path State Removed checks if the
   LSP it refers to is involved in an Adoption procedure, whose track is
   kept until successful end of signaling flow has been carried on as
   stated above. If yes, then no actions are performed over the data
   plane, while GMPLS status information about involved LSP over Control
   Plane is deleted and the cross connection ownership is moved back
   under the NMS controls.

Caviglia et al.           Expires - August 2005               [Page 6]

draft-caviglia-mp2cpcp2mp-02                           February 2005

   The same applies for PathTear message.
## Ah. Very important!
## In fact, rather than limiting to the PathErr with PSR flag, and
## PathTear, why don't you say that "While the Handover flag is set in
## the Administrative Status object of the associated Path message, an
## LSR MUST NOT make changes to the data plane state (resource
## reservations, cross-connects, etc.) as the result of either Control
## Plane or Management Plane actions.

2.3 LSP Release phase- disassociation of GMPLS information to a MP born,
    CP adopted LSP - LSP Tear Down

   This Section covers the procedure needed to manage a LSP Release
   procedure (as a dual, opposite procedure respect to Adoption
   described above).

   Such a procedure is performed at a signaling level as described in
   Section 7.2.1 of the RFC 3473 [4]. LSP tear down flow is carried on
   as usual, except that Handover flag is set in Administrative Status
   Object like it was during set-up (adoption) case.
## Although this reference is correct, I think you could usefully give
## some hints. That is, explain that the procedures are the same as for
## alarm-free teardown using the Adminastrative Status object as
## described in...

   Nodes receiving G.RSVP-TE tear down messages with Handover flag set,
## No, no, no, no!
## There is no Admin Status object on a PathTear. Go back and read the
## reference you cited! What you have to do is:
##
## 1. Turn on Handover and Refelect bits in Admin Status on a Path
## 2. Wait until the Handover bit is received back in the Resv
## 3. Send PathTear to release the CP state.
## 4. Apply the same rule as above. That is:
##    While the Handover flag is set in
##    the Administrative Status object of the associated Path message,
##    an LSR MUST NOT make changes to the data plane state (resource
##    reservations, cross-connects, etc.) as the result of either
##    Control Plane or Management Plane actions.

   have to process such messages as usual, but they have to behave in a
   special way respect to Data Plane. As a perfect dual situation of the
   Adoption described before, no actions at all have to be performed
   over the data plane. This means that the node has to carry on tear
   down signaling procedure but it SHOULD NOT clear x-connection related
   to affected LSP. As a consequence of the Release only GMPLS state
   information have to be deleted.

   At the end of the Disassociation procedure the GMPLS associated
   information is deleted and the LPS is moved under the NMS control.

## You need to add sections to describe:
## - Control Plane failure and recovery during handover
## - Non-support of the handover process by transit or egress LSRs

3. RSVP Message Formats

   This memo does not introduce any modification in RSVP messages.

3.1 Object Modification

   This memo introduces a new flag into the Administrative Status
   object.

3.1.1 Administrative Status Object

## Say...
## The Admin_Status Object is defined in RFC 3473 [4].
##
## This document uses the H-bit of the Admin_Status object. The bit
## is bit number (TBD by IANA).

##### START DELETE
#  The use of the Admin_Status Object is optional.  It uses Class-Number
#  196 (of form 11bbbbbb).
#
#     The format of the Admin_Status Object is:
#
#      0                   1                   2                   3
#      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
#     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
#     |            Length             | Class-Num(196)|   C-Type (1)  |
#     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
#     |R|                        Reserved               |H|L|I|C|T|A|D|
#     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
#
#
#Caviglia et al.           Expires - August 2005               [Page 7]
#
#draft-caviglia-mp2cpcp2mp-02                            February 2005
#
#        Reflect (R): 1 bit
#
#        When set, indicates that the edge node SHOULD reflect the
#        object/TLV back in the appropriate message.  This bit MUST NOT
#        be set in state change request, i.e., Notify, messages.
#
#        Reserved: 28 bits
#
#        This field is reserved.  It MUST be set to zero on transmission
#        and MUST be ignored on receipt.  These bits SHOULD be pass
#        through unmodified by transit nodes.
####### END DELETE

         Handover signaling (H): 1 bit

         When set, indicates that an Association/Disassociation
         procedure is ongoing.
## Why not call this the ahndover procedure?

####### START DELETE
#  The other flag are defined in the following documents:
#        R-bit   [RFC3471]
#        L-bit   [E2E]
#        I-bit   [ALARM]
#        C-bit   [ASON]
#        T-bit   [RFC3471]
#        A-bit   [RFC3471]
#        D-bit   [RFC3471]
#
#
#  Where:
#   [RFC3471]     RFC3471
#   [E2E]         draft-ietf-ccamp-gmpls-recovery-e2e-signaling
#   [ALARM]       draft-ietf-ccamp-gmpls-alarm-spec
#   [ASON]        draft-ietf-ccamp-gmpls-rsvp-te-ason
####### END DELETE

4. Security Considerations

   This document does not introduce any additional Security issues.  For
   GRSVP-TE Security please refer to [3].

## I think that the removal of an LSP from one sphere of control to
## another is a serious security issue. You need to explain this risk
## and state why it is or is not a problem.

5. IANA Consideration

   This memo introduces a new GRSVP-TE object type and a new Error Code
   Error Value couple.
##
## Hmmm? What new object type? What new error code/value?
##
## Say the following...
## 6.1 Administrative Status Bit Allocation
##
## IANA has been asked to manage the bit allocations for the
## Administrative Status object [6].
##
## This document requires the allocation of the Handover bit: the H-bit.
## IANA is requested to allocate a bit for this purpose. See section
## 3.1.1.

6. Normative References

   1  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
      9, RFC 2026, October 1996.

   2  Bradner, S., "Key words for use in RFCs to Indicate Requirement
      Levels", BCP 14, RFC 2119, March 1997.

Caviglia et al.           Expires - August 2005               [Page 8]

draft-caviglia-mp2cpcp2mp-02                            February 2005

   3  Berger, L., " Generalized Multi-Protocol Label Switching (GMPLS)
      Signaling Functional Description", RFC 3471, January 2003

   4  Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS)
      Signaling Resource ReserVation Protocol-Traffic Engineering
      (RSVP-TE) Extensions", RFC 3473, January 2003.

7. Informational References

   5  Zamfir, A., " Component Link Recording and Resource Control for
      GMPLS Link Bundles",
      draft-zamfir-explicit-resource-control-bundle-03, February 2004.
## state "work in progress"

## 6  L. Berger (Ed.) "GMPLS - Communication of Alarm Information",
      draft-ietf-ccamp-gmpls-alarm-spec-02.txt, November 2004, work in
      progress.

8. Acknowledgements

   Adrian Farrel provided editorial assistance to prepare this draft
   for publication.

9. Author's Addresses

   Diego Caviglia
   Marconi
   Via A. Negrone 1/A
   Phone: +390106003738
   Email: [email-masked]

   Dino Bramanti
   Marconi
   Via Moruzzi 1
   C/O Area Ricerca CNR, Pisa
   Email: [email-masked]

   Nicola Ciulli
   Nextworks
   Corso Italia n. 116,
   56125 Pisa (Italy)
   Email: [email-masked]

10. Intellectual Property Rights Notices

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights. Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

Caviglia et al.           Expires - August 2005               [Page 9]

draft-caviglia-mp2cpcp2mp-02                         February 2005

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard. Please address the information to the IETF at
   [email-masked].

11. Full Copyright Statement

   Copyright (C) The Internet Society (2005). This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Caviglia et al.           Expires - August 2005              [Page 10]

---

From: "Diego Caviglia" <[email-masked]>
Date: Tue, 7 Jun 2005 16:02:53 +0200

Hi Adrian,
           thank you for your valuable comments.

We'll take them in consideration reviewing the ID, hopefully we'll be able
to present it to Paris if there room for that.

Best Regards

Diego

"Adrian Farrel" <[email-masked]> on 04/06/2005 14.28.37

Please respond to "Adrian Farrel" <[email-masked]>

To:    "Diego Caviglia" <[email-masked]>
cc:    <[email-masked]>, <[email-masked]>,
       <[email-masked]>

Subject:    Review of draft-caviglia-mp2cpcp2mp-01.txt

Hi Diego,

Regards,
Adrian

===========

                                                           Nicola Ciulli
                                                               Nextworks

                                                           February 2005

Status of this Memo

Copyright Notice

Abstract

Table of Contents

1. Introduction

2. LSP Adoption/Release

2.1 Overview

   Case 1:

   Case 2:

3. RSVP Message Formats

3.1 Object Modification

## Say...

##### START DELETE

####### START DELETE

5. IANA Consideration

6. Normative References

8. Acknowledgements

9. Author's Addresses

   Diego Caviglia
   Marconi
   Via A. Negrone 1/A
   Phone: +390106003738

   Dino Bramanti
   Marconi
   Via Moruzzi 1

   Nicola Ciulli
   Nextworks
   Corso Italia n. 116,
   56125 Pisa (Italy)