Subject: RE: Moving LSP ownership between control plane and management plane

From: <[email-masked]>
Date: Tue, 19 Jul 2005 22:36:27 +0100

Hi George....nice to hear from you...hope all is well with you,

This all sounds very reasonable to me.  At the end of the day, all a
signalling protocol is is a distributed agent of network
management.....in the types of large BW granularity networks being
discussed the NMS will always be king.   Sorry if that's a problem to
some folks, its just a fact for the way we see/implement it.

This also follows from a good understanding of the commercials at play
here.  That is, there is a major difference between:
-	a public service context (cf PSTN), or extending a similar
capability out to end-systems in the co-ps mode say, where
end-systems/applications drive trail set-up (ie SVCs across a UNI).
Here one hopes there could be a large population of users (think
peer-peer/BB) and that the trail holding-times are not 'too long'.  In
this environment there could be a viable business case based on a
providing a given GoS at some cost.....and it might solve some
(otherwise) hard QoS/pricing problems for operators....but I digress;
-	a private network builder service context where one is a
providing a (relatively long time-constant) traffic-engineering function
to a higher layer network, ie creating its topology.  This is a
client/server relationship and THE starting point for this must be
functional decoupling of the client and server layer networks because
they will often be owned by different parties.  We are talking
relatively long forecast/planning cycles here and long trail holding
times....esp when it comes to real physical build.  Further, the
potential population is rather small compared to the previous case.  If
folks look at whether there is a viable business case here based on a
providing a given GoS at some cost in an acceptable time period I
suspect they will be disappointed.

What this all means is that the control-plane is not such an important
topic as we move down the layered network stack towards the
duct....increasingly other factors like strong NMS and OAM assume a far
greater importance.  This is not to say a control-plane is not useful
but:
-	we should be clear there cannot be any common addressing and
routing functions across a set of nested layer networks, which is very
obvious when different parties own different layer networks....one can
(and should) re-use components (if they are the right ones), but they
will need to operate in different layer network spaces
-	signalling is a useful agent for functions like S-PVCs and
resilience.

Well that's our analysis anyway....if anyone knows different I'd be
happy to review their commercial assumptions with folks here.

regards, Neil

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of George Newsome
> Sent: 19 July 2005 12:44
> To: Adrian Farrel
> Cc: [email-masked]
> Subject: Re: Moving LSP ownership between control plane and
> management plane
> 
> 
> Adrian,
> 
> You asked for comments on this proposal, which was presented to ITU-T 
> Q14 experts in January of this year.
> 
> There are so many issues involved in moving a connection from the 
> management plane to the control plane that involve intensive 
> management action, that it is not evident that signaling need be 
> involved at all.
> 
> As a personal opinion, it makes little sense to consider moving the 
> connection. It makes more sense to replace the connection with one set
> up via the control plane, and to then delete the original 
> management set 
> up connection.
> 
> Appended is an excerpt of the meeting report detailing some of the 
> issues that need to be resolved before signaling need be considered.
> 
> Regards
> 
> 	George
> 
> Excerpt of the meeting report of Q14 Experts, January 2005
> 
> WD06 (Marconi) "G.7713 Modification in order to support Circuit 
> Migration" contains a modified version of draft G.7713 Revision as was
> presented in the Berlin meeting (WD 11, i.e., TD50/3 Dec.2004).  This 
> contribution addresses SP24 (PC ? SPC) of G.7713. It proposes 
> to extend 
> the concept of Call/Connection setup to setup/adopt and release to 
> release/de-adopt. In Connection Adoption both the SNC are not 
> actually 
> created and the LC are not actually established due to the 
> fact that the 
> underlying physical resources are already in place. In the 
> Call/Connection dis-adoption SNC-LC-SNC is not actually de-allocated, 
> only the Control Plane information associated with then is 
> removed and 
> the ownership is moved to Management Plane. Attributes for indicating 
> Adoption/Dis-adoption are proposed for the INNI Connection messages.
> 
> The discussion was mainly on the Management plane and Control plane 
> actions required before signalling is involved. The group noted that 
> the following issues need to be addressed:
> 
> - Naming of transport resources to the control plane.  Before a call 
> can be placed under signalling control, links that are involved in the
> connection need to be given control plane names.  Without these, no 
> explicit route can be formed to match the resources of the connection.
> 
> - Resource state while under dual CP and MP views.  After resources 
> are given control plane names, the resources are still viewed by the
> management plane.  It may be necessary to create a new state for the 
> resource to indicate that the management plane cannot perform some 
> actions on the connection points as the control plane is 
> about to take over.
> 
> - Role of discovery functions (esp. CELA).  After control plane names 
> are allocated, distributed control plane functions need to be 
> associated and communication adjacencies formed.  This too is a 
> precursor to any signalling procedures in migrating from the MP to CP.
> 
> - Similarity of migration to synchronization after CP failure and 
> subsequent recovery.  Connection control procedures might be the same 
> in migrating a call from the MP to the CP as the situation when
> the CP has 
> failed and is recovering.  Here, the network connections are 
> already in 
> place, but connection and call state need to be created to match it. 
> Knowledge of the call and what the connection should be is 
> obtained from 
> the MP for migration, and from some reliable database in the 
> recovery case.
> 
> - Call awareness of migration vs. connection being unaware of 
> migration.
>   When connection state is being created to match an existing
> connection, the connection controllers (CCs) do not require 
> awareness of 
> why this is happening as the context could be migration or 
> recovery.  A 
> mechanism to create control state without affecting transport plane 
> state is needed in the CCs.  Call controllers though do need 
> migration 
> awareness as they need to obtain/derive call identification 
> from the MP.
> 
> In summary, the group decided that it is premature to consider 
> signalling procedure before the above issues, amongst other, have been
> studied. However the contribution does enable the group to 
> expose in a 
> larger context the interaction between CP and MP for connection 
> migration. The above issues were included in SP24 of the 
> G.7713 Living 
> List (see WD22).
> 
> 
> 
>

---

From: "Dino Bramanti" <[email-masked]>
Date: Wed, 20 Jul 2005 09:15:56 +0200

Thanks Adrian for commenting on proposed ID.
I do agree basically with everything you are saying in your post.
I confirm that our intention was trying to define a simple control plane
mechanism, with (very) low impact on
existing GRSVPTE procedures and message set, but still able to control the
handover of LSP ownership between planes.

In fact I agree that the definition of procedures within management plane
to be done prior to LSP signaling within control plane are quite
a complicated work, requiring probably a bigger effort.
However, the proposed handover procedure has to take place conceptually and
temporally after the information collection phase (and address translation
/ parameter mapping between management plane and control plane "language")
and it is not dependent on how this is done.
If we accept that signaling mechanism has to be involved "somehow" in a LSP
handover operation (and I think so, for the very same reasons as Adrian in
his post), then we can try to resolve the whole problem of MP/CP migration
of LSP looking separately at its different phases. The phase covering the
collection of the whole information required to signal a LSP over control
plane is outside the scope of the ID, which takes it as a starting point
for the definition of proposed mechanism. That is, we assume that MP has to
provide CP with all the information needed to format a valid GRSVPTE path
message, this being possible because the dataplane of the LSP to be handed
over is already in place and in service and visible from its current owning
plane.

dino

Thanks George,

Useful input.

> Q14 experts in January of this year.

Can you confirm that there were plenty of providers represented at the
meeting.

> management plane to the control plane that involve intensive management
> action, that it is not evident that signaling need be involved at all.

Interesting. It is certainly valuable to have a list of these issues out
in the open. I have made some comments in the appended meeting report.

If the control plane is to take over the connection then we assume that
signaling state must be built so that the control plane could then modify
or tear down the connection. how would you propose that this be done
without involving signaling?

> up via the control plane, and to then delete the original management set
> up connection.

The question arrises of how this would be done in a network with limited
resources. That is, if it is possible to set up a parallel conneciton then
the method you describe would be fine, but if there are not enough
parallel resources then would you propose that a lambda (for example)
could be used for the management-established connection and for the
control-plane-owned connection at the same time? This might present some
difficulties as well.

Do you have an opinion on my main question which is whether this tyoe of
change-over would ever be done in service?

Thanks,
Adrian

> contribution addresses SP24 (PC ? SPC) of G.7713. It proposes to extend
> release/de-adopt. In Connection Adoption both the SNC are not actually
> created and the LC are not actually established due to the fact that the
> only the Control Plane information associated with then is removed and
> actions required before signalling is involved. The group noted that the
> following issues need to be addressed:
>
> - Naming of transport resources to the control plane.  Before a call can
> be placed under signalling control, links that are involved in the

This is pretty obvious. But actually, this is an issue with moving the
resources from one plane to another (or having them present in both
planes). It is certainly a prerequisite for moving the connection, but it
is not functionally an element of moving the connection.

The draft, as I read it, assumes that these operations have been completed
and then asks "how do I move the connection from one plane to the other?"

> - Resource state while under dual CP and MP views.  After resources are
> given control plane names, the resources are still viewed by the
> actions on the connection points as the control plane is about to take
over.

Yes. There is certainly scope for a race condition here. I believe that
the I-D proposes to (try to) make the transfer an atomic action from the
point of view of the change-over.

Note, however, that it is wrong to assume that a resource belongs only to
the control or to the management plane at any moment in time. This may be
true with respect to the ability to provision/control connections, but
resources that are available for use by the control plane can still be
managed through the management plane. Thus, you take a laser out of
service through the management plane, not through the control plane.

> are allocated, distributed control plane functions need to be associated
> and communication adjacencies formed.  This too is a precursor to any
> signalling procedures in migrating from the MP to CP.

Note to CCAMP: CELA is Control Entity Logical Adjacency.
This too is "obvious".
But this discussion seems to be wide of the mark. Before deploying a
control plane, it is clear that this type of operation needs to take
place. Since (within the context of CCAMP) a control plane *is* going to
be deployed, we can assume this operation and move on to the discussion in
the draft.

> subsequent recovery.  Connection control procedures might be the same in
> migrating a call from the MP to the CP as the situation when the CP has
> failed and is recovering.  Here, the network connections are already in
> Knowledge of the call and what the connection should be is obtained from
> the MP for migration, and from some reliable database in the recovery
case.

This is a valid point.
Control plane failure, however, is unlikely to be total. That is, it would
be unusual for more than one control plane link or node to fail. Thus, in
the control plane, the "reliable database" is distributed and recovery can
follow the procedures outlined in draft-ietf-ccamp-rsvp-restart-ext-03.txt

It would certainly be worth considering whether the procedures used for
control plane recovery could be applied to transfer of ownership from the
management to control plane. at the moment, I suspect that they could not
because the restart extensions assume a specific period during which
signaling is associated with recovery.

We would also need to look at the reverse process (transfer from CP to MP)
that is not possible to cover by CP restart procedures.

> - Call awareness of migration vs. connection being unaware of migration.
> connection, the connection controllers (CCs) do not require awareness of
> why this is happening as the context could be migration or recovery.  A
> state is needed in the CCs.  Call controllers though do need migration
> awareness as they need to obtain/derive call identification from the MP.

I disagree.
Connection controllers must be able to distinguish between resources that
are already in use and cannot be assigned to a new connection, and those
that are already in use and can be assigned to a new connection because
the connection is replacing an existing connection. If this were happening
entirely within the control plane we would use resource sharing, but when
the operation spans the control and management planes resource
ownership/sharing is more complex and the conneciotn controller needs to
be able to issue the approriate instrucitons for the assignment of the
resources.
On the other hand, call controllers do not need awareness of the details
of the realisation of the connections.

> studied. However the contribution does enable the group to expose in a
> migration. The above issues were included in SP24 of the G.7713 Living
> List (see WD22).

---

From: "Diego Caviglia" <[email-masked]>
Date: Wed, 20 Jul 2005 09:51:43 +0200

Hi Neil,
         it always a pleasure read your e-mail but I think I'm missing
something.

The basic purpose of the ID is to provide a simple mechanism to move LSPs
from a domain to another, I don't see any implication, with layering.
Better to say this ID have the same implication with layering as 'normal'
signalling.

Moreover I agree with you that NMS is the 'king' of the network and in fact
the ID forseen that is MNS to provide the right information to CP to move
the LSP from a domain to another one.

My basic question is: do someone think that having a mechanism to move
MP/CP created LSP under the CP/MP domain is useless?

My experience tell me that the answer is no, but I'm open to discuss this.

Regards

Diego

<[email-masked]>@ops.ietf.org on 19/07/2005 23.36.27

Sent by:    [email-masked]

To:    <[email-masked]>, <[email-masked]>
cc:    <[email-masked]>

Subject:    RE: Moving LSP ownership between control plane and management
       plane

regards, Neil

---

From: "Diego Caviglia" <[email-masked]>
Date: Wed, 20 Jul 2005 10:13:55 +0200

Hi Geroge,
           I remember quite well that discussuion, but I also remember that
the common feeling was that the proposed feature is useful.

I can agree that this implies some discussion on the naming of the resource
and so on but the ID assumes that all this stuff has been resolved.

Some more comment in line.

Regards

Diego

George Newsome <[email-masked]>@ops.ietf.org on 19/07/2005 13.44.29

To:    Adrian Farrel <[email-masked]>
cc:    [email-masked]

Subject:    Re: Moving LSP ownership between control plane and management
       plane

Adrian,

There are so many issues involved in moving a connection from the
management plane to the control plane that involve intensive management
action, that it is not evident that signaling need be involved at all.
[dc] I agree with the fisrt part of your sentence but not with the second.
From a CP point of view 'adopt' a LSP or create a new one is more or less
the same (in fact the ID basically adds only one bit to the already
existing signalling protocol) so saying that '...is not evident that
signaling need be involved at all' for an adoption can be extended to
signaling in general and that is why I disagree.

As a personal opinion, it makes little sense to consider moving the
connection. It makes more sense to replace the connection with one set
up via the control plane, and to then delete the original management set
up connection.
[dc] Sorry but seems that this is traffic affecting that is something that
usually operators wants to avoid.

Regards

             George

- Naming of transport resources to the control plane.  Before a call can
be placed under signalling control, links that are involved in the
connection need to be given control plane names.  Without these, no
explicit route can be formed to match the resources of the connection.
[dc] This is outside the scope of the ID and probabily also from the scope
of the CCAMP/IETF.
We assume that this point has been resolved in the ID.

- Resource state while under dual CP and MP views.  After resources are
given control plane names, the resources are still viewed by the
management plane.  It may be necessary to create a new state for the
resource to indicate that the management plane cannot perform some
actions on the connection points as the control plane is about to take
over.
[dc] Again this is a NMS related issue that is uotside the scope of the
ID/CCAMP and may be IETF.

[dc] Yes but the ID assumes that this has been done.

- Similarity of migration to synchronization after CP failure and
subsequent recovery.  Connection control procedures might be the same in
migrating a call from the MP to the CP as the situation when the CP has
failed and is recovering.  Here, the network connections are already in
place, but connection and call state need to be created to match it.
Knowledge of the call and what the connection should be is obtained from
the MP for migration, and from some reliable database in the recovery case.
[dc] Adrian comment is also my comment

[dc] As above.

---

From: <[email-masked]>
Date: Wed, 20 Jul 2005 09:56:04 +0100

Hi Diego.....No I don't think what you are saying is useless, and I'm
sorry if that was the impression I conveyed .......in fact you MUST
consider these aspects (eg the ones George flagged) when you add a CP.
What I was trying to point out is the IMPORTANCE of a CP here relative
to other stuff.  Let me just play out the logic again as briefly as I
can.

As we move towards the duct the importance/value of the control-plane
diminishes.  So for addressing S-PVCs and resilience issues its
fine......where I have grave doubts are those who think they can create
'topology on the fly' (for other client layer networks).  A key factor
here is acceptable GoS/business models....our studies indicate that to
be viable one would need a waiting time (post demand epoch) of at least
the same order as the expected holding time.....now figure out what that
really means.  And of course this still assumes everything BELOW this
SVC level is already provisioned.  

Then there is the issue of 'who owns which layer?'.....and this means
the overriding requirement that must be addressed 1st is client/server
functional decoupling.  Closely related to this 'who owns which layer'
issue is how the 3 planes of one layer network are provided over the
*traffic plane* of another/lower layer network....and I gave a very
detailed response to Igor on this recently.

And once you piece it all together then you realise we can't have full
convergence from IP to Optics....and a smart observer at this point
might ask 'so why are folks being prescriptive about the choice of
functional components, eg addressing, signalling, routing?'  For example
I could postulate that PNNI is a better signalling protocol than RSVP
...and why would anyone in their right minds start with v4 addressing
when they already know its problems? Should at least use v6 here IMO.
Maybe I only need static routing and this should be a centralised
function?  

And finally...even when you add the CP it is fact of life, with which I
see you agree, that the MP is still king here.....a CP without a good MP
is rather useless.

regards, neil

> From: Diego Caviglia [mailto:[email-masked]]
> Sent: 20 July 2005 08:52
> To: Harrison,N,Neil,IKM1 R
> Cc: <gnewsome; <adrian; <ccamp
> Subject: RE: Moving LSP ownership between control plane and 
> management plane
> 
> 
> 
> Hi Neil,
>          it always a pleasure read your e-mail but I think
> I'm missing something.
> 
> The basic purpose of the ID is to provide a simple mechanism
> to move LSPs from a domain to another, I don't see any 
> implication, with layering. Better to say this ID have the 
> same implication with layering as 'normal' signalling.
> 
> Moreover I agree with you that NMS is the 'king' of the
> network and in fact the ID forseen that is MNS to provide the 
> right information to CP to move the LSP from a domain to another one.
> 
> My basic question is: do someone think that having a
> mechanism to move MP/CP created LSP under the CP/MP domain is useless?
> 
> This all sounds very reasonable to me.  At the end of the
> day, all a signalling protocol is is a distributed agent of 
> network management.....in the types of large BW granularity 
> networks being
> This also follows from a good understanding of the
> commercials at play here.  That is, there is a major 
> difference between:
> end-systems/applications drive trail set-up (ie SVCs across a 
> UNI). Here one hopes there could be a large population of users (think
> peer-peer/BB) and that the trail holding-times are not 'too 
> long'.  In this environment there could be a viable business 
> case based on a providing a given GoS at some cost.....and it 
> might solve some
> providing a (relatively long time-constant) 
> traffic-engineering function to a higher layer network, ie 
> creating its topology.  This is a client/server relationship 
> and THE starting point for this must be functional decoupling 
> of the client and server layer networks because they will 
> often be owned by different parties.  We are talking 
> relatively long forecast/planning cycles here and long trail 
> holding times....esp when it comes to real physical build.  
> Further, the potential population is rather small compared to 
> the previous case.  If folks look at whether there is a 
> viable business case here based on a providing a given GoS at 
> some cost in an acceptable time period I suspect they will be 
> disappointed.
> 
> What this all means is that the control-plane is not such an
> important topic as we move down the layered network stack 
> towards the duct....increasingly other factors like strong 
> NMS and OAM assume a far greater importance.  This is not to 
> say a control-plane is not useful
> but:
> routing functions across a set of nested layer networks, 
> which is very obvious when different parties own different 
> layer networks....one can (and should) re-use components (if 
> they are the right ones), but they will need to operate in 
> different layer network spaces
> Well that's our analysis anyway....if anyone knows different
> I'd be happy to review their commercial assumptions with folks here.
> 
> 
> regards, Neil
> 
> management
> management
> > set up connection.
> > contribution addresses SP24 (PC ? SPC) of G.7713. It proposes to
> > extend the concept of Call/Connection setup to setup/adopt 
> and release
> > to release/de-adopt. In Connection Adoption both the SNC are not 
> > actually created and the LC are not actually established due to the
> > fact that the
> > only the Control Plane information associated with then is removed 
> > and the ownership is moved to Management Plane. Attributes for
> indicating
> about to take
> > in migrating a call from the MP to the CP as the situation
> when the CP
> > has failed and is recovering.  Here, the network connections are 
> > already in place, but connection and call state need to be created 
> > to match it. Knowledge of the call and what the connection should be

> > is obtained from
> awareness
> > of why this is happening as the context could be migration or 
> > recovery.  A mechanism to create control state without affecting 
> > transport plane state is needed in the CCs.  Call controllers though

> > do need migration
> > migration. The above issues were included in SP24 of the G.7713 
> > Living List (see WD22).
> >
> >
> >
> >
> 
> 
> 
> 
> 
> 
>

---

From: [email-masked]
Date: Wed, 20 Jul 2005 11:30:35 +0200

diego -

"My basic question is: do someone think that having a mechanism to move
MP/CP created LSP under the CP/MP domain is useless?"

no -

in part. the MP->CP handover is a key mechanism for migration toward GMPLS CP

-dimitri.

---

From: "Diego Caviglia" <[email-masked]>
Date: Wed, 20 Jul 2005 11:32:04 +0200

Hi Geroge,
           sorry but I don't see how the management effort is something
related to this ID and more in general with CCAMP.

There are already RFC ID that provide tools to signal LSP with ERO filled
up to the Label level and of course this can be done only via management, I
don't remeber any objections on that due to NMS impact.

I'd like to discuss here (I mean in the CCAMP ML) about the ID, that is, if
it useful and if could work and not about the difficulties it implies for
the NMS.

I'm open to discuss, and actually I did, NMS related issues on the ITU-T
ML.

Regards

Diego

George Newsome <[email-masked]>@ops.ietf.org on 20/07/2005 11.03.00

To:    Adrian Farrel <[email-masked]>
cc:    [email-masked], Neil Harrison <[email-masked]>, Dino
       Bramanti <[email-masked]>

Adrian, Dino, etc.,

This thread has rapidly got too long, and I don't have the time at the
moment to argue the toss, so I'll reply as a note rather than
intersperse remarks.

On Adrian's question of which operators were at Holmdel - AT&T and
T-Systems. On do operators think they want this - some do some don't.
BT clearly don't see much value in fiddling with signaling.

You ask whether this might be done in service, and there are certainly
those who would like to see just that. Related questions are how many
times in the life of the system might this be done for the same
connection? Is it cost effective to develop a highly reliable solution
that is used just once in the life of the system?

However this is not so much a discussion of whether this could be
useful, but a technical discussion of whether changing a bit (and a slew
of procedures) in a signaling protocol actually provides the claimed
facility.

Because of the effort the management system needs to provide before
signaling might be involved, changing the signaling protocol gives the
illusion of success, yet does not provide the claimed service at all.

Once the management systems have got as far as assigning control plane
names, we can ask what happens to the cross connect object when it is
deleted as part of the hand off procedure? The behavior of this object
is that its deletion results in dropping the matrix connection, which is
exactly not required during the change over.

It is my considered opinion that fiddling with signaling merely
obfuscates the significant difficulties, which are glossed over by
stating that those difficulties occur at a different time.

Regards

             George

---

From: "Diego Caviglia" <[email-masked]>
Date: Wed, 20 Jul 2005 11:37:09 +0200

Dimitri,
         yes of course the main application is MP-->CP the CP-->MP is just
for simmetry;-))

Diego

[email-masked] on 20/07/2005 11.30.35

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

diego -

no -

in part. the MP->CP handover is a key mechanism for migration toward GMPLS
CP

-dimitri.

---

From: "Diego Caviglia" <[email-masked]>
Date: Wed, 20 Jul 2005 11:44:13 +0200

Sorry for this but may be not all have read the ID, I hope that having the
text help the discussion.

Regards

Diego

   Network Working Group
   Internet Draft                                        Diego Caviglia
   Document: draft-caviglia-mp2cpcp2mp-02.txt             Marconi
   Proposed Status: Updates RFC 3473                      Dino Bramanti
                                                                Marconi
   Expires: December 2005                                 Nicola Ciulli
                                                              NextWorks

                                                              June 2005

     GMPLS Signaling Extensions for the Transfer of Ownership of Label
         Switched Paths Between the Management and Control Planes

   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 becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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/1id-abstracts.html

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

Abstract

   During migration scenarios it may be desirable to transfer the
   ownership of a Label Switched Path (LSP) from the Management Plane
   (MP) to the Control Plane (CP), 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 Multi Protocol
   Label Switching (GMPLS) signaling protocol, GRSVP_TE (Generalized
   Resource Reservation Protocol with Traffic Engineering Extensions),

Caviglia et al.        Expires - December 2005               [Page 1]
                     draft-caviglia-mp2cpcp2mp-02            June 2005

   to enable such transfer of ownership and describes the proposed
   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 [1].

Table of Contents

   1. Introduction...................................................2
   2. Problem Explanation............................................3
   3. Proposed solution..............................................3
   4. LSP Ownership Handover Procedure Between Management And Control
   Planes............................................................5
      4.1 "MP to CP handover" - LSP Ownership Transfer From Management
      Plane To Control Plane.........................................5
      4.2 MP to CP Handover Procedure Failure Handling...............8
      4.3 "CP to MP handover" - LSP Ownership Transfer From Control
      Plane To     Management Plane..................................8
      4.4 CP to MP Handover Procedure Failure Handling...............9
   5. RSVP Message Formats..........................................10
      5.1 Object Modification.......................................10
   6. Security Considerations.......................................10
   7. IANA Consideration............................................10
   8. References....................................................11
   9. Acknowledgments...............................................11
   Author's Addresses...............................................11

1. Introduction

   In a typical, traditional transport network scenario, Data Plane
   connections between two endpoints are controlled basically by means
   of a Network Management System (NMS) operating within Management
   Plane (MP). NMS/MP is the owner of such transport connections, being
   responsible of their set up, tear down and maintenance. The adoption
   and use of a GMPLS Control Plane over networks that are controlled by
   NMS at Management Plane level and that are already in service could
   not be considered a green field application. In this context, let's
   indicate with the term Label Switched Path (LSP) the Data Plane
   forwarding path and Data Plane state associated to a connection,
   whose control is owned by either Management or Control Plane (via
   GRSVP-TE). In a mixed scenario, LSPs owned by Management Plane and
   LSPs owned by Control Plane have to coexist and a way to move their
   control and ownership between planes, while preserving corresponding

Caviglia et al.        Expires - December 2005               [Page 2]
                     draft-caviglia-mp2cpcp2mp-02            June 2005

   Data Plane traffic, is needed. It is in fact possible that a network
   operator wants to move the control of a Management Plane owned
   transport connection to Control Plane and, in the same way, the
   opposite operation is also needed. In this memo let's indicate with
   "MP to CP handover" the procedure that is aimed at moving the control
   and ownership of a transport connection owned by Management Plane to
   Control Plane. Let's call "CP to MP handover" the opposite procedure,
   aimed at moving the ownership of a LSP from Control Plane to
   Management Plane.

2. Problem Explanation

   Having the ownership of a LSP means basically having the access to
   the information associated to a physical Data Plane connection
   between two endpoints (ingress and egress of LSP) that traverses a
   list of nodes. The owner of a LSP has to store and use such
   information (LSP hop list, associated TE information etc.) to control
   completely the LSP. Let's take the case of a Data Plane connection
   between an ingress node and an egress node, which has been set up by
   means of NMS. The network resources allocated to this connection
   cannot be used or controlled by GRSVP-TE as it doesn't have any
   information record about it. If a standard GRSVP-TE setup request
   over the same resources was issued, the nodes will reject it, as they
   find the involved resources already allocated. A standard GRSVP-TE
   release request for that LSP wont be successful as well, because LSP
   related information to be matched with the one sent in signaling
   messages is not available at Control Plane level.
   If a Data Plane connection between an ingress node and an egress has
   been set up via GRSVP-TE signaling, all the info related to the LSP
   is present at Control Plane level which is the owner of that
   connection. If NMS wants to take over the LSP, the Control Plane has
   to be informed that involved resources are no more under its control.
   In both cases, the point is that the Data Plane connection has to
   stay up, but related information allowing control of the LSP has to
   be handed over to Control Plane or Management Plane. In other words,
   a handover of LSP ownership between planes means that Data Plane
   circuit has to stay untouched in terms of topology and resources
   allocated, not only in terms of carried traffic.

3. Proposed solution

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

Caviglia et al.        Expires - December 2005               [Page 3]
                     draft-caviglia-mp2cpcp2mp-02            June 2005

   above. The idea is that standard GRSVP-TE signaling flow can be used
   to inform nodes about the ownership handover procedure, where such
   flow has to be flagged in order to distinguish it from normal LSP
   setup/release procedure. When a LSP owned by Management Plane has to
   be handed over to Control Plane, a signaling set-up with HANDOVER
   flag set has to be sent from ingress node. At ingress node all the
   information related to the LSP is passed to GRSVP-TE, which uses it
   to fill in the PATH message (Explicit Route Object - ERO, Traffic
   Engineering and context information). Such PATH message, sent with
   HANDOVER flag set, reaches the nodes along the LSP path and informs
   them that the referred LSP is already present at Data Plane level and
   that it has to be adopted by Control Plane. After a node has received
   such special PATH, it becomes owner of the LSP and treat it like any
   other LSP set up via GRSVP-TE. Let's call this procedure "MP to CP
   handover".
   The opposite procedure "CP to MP handover" works in a similar way.
   When a LSP owned by Control Plane has to be handed over to Management
   Plane, a signaling PATH DOWN with HANDOVER flag set has to be sent
   from ingress node along the LSP path, informing involved nodes that a
   CP to MP handover is in progress for that LSP.
   The information about that LSP under control within GRSVP-TE scope is
   passed to Management Plane at ingress node, and in every node, which
   receives flagged PATH DOWN. A node is able to recognize such special
   PATH DOWN by reading the handover flag value. If a node finds that
   flag set, then it is aware that that the related LSP has to stay
   untouched at Data Plane level, but its ownership has to be passed to
   Management Plane. It is worth stressing that, 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 formerly owned by MP,
   signaled within CP with Handover flag set (i.e. handed over to CP)
   can be deleted by usual relevant Control Plane signaling flows (i.e.
   with Handover flag not set). The same applies when considering the
   handover of a LSP from CP to MP when, at the end of procedure, the
   LSP belongs to Management Plane and can be fully controlled by NMS.
   In other words, after the 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 for that
   entity.
   This is in some way similar to the Restart Procedure, (Section 4.3
   RFC 3473 [5]), in the sense that the status of the physical resources
   at Data Plane has to stay unmodified but the associated information
   allowing its control has to be transferred. 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.
   Following section gives detailed description of proposed "MP to CP
   handover" and "CP to MP handover" procedures.
   In the following the handover of a bidirectional LSP is assumed. The
   case of unidirectional LSP can be easily derived from that.

Caviglia et al.        Expires - December 2005               [Page 4]
                     draft-caviglia-mp2cpcp2mp-02            June 2005

4. LSP Ownership Handover Procedure Between Management And Control
   Planes

   Resv Confirm message within LSP setup signaling flow SHOULD be
   supported in order to manage at best LSP Ownership Handover Procedure
   Between Control And Management Planes. If Resv Confirm is not present
   in message set used for LSP setup, the handover procedure described
   below is still applicable using the simple Path/Resv sequence (with
   handover flag set as detailed in the following). In that case,
   handover related operations that in the following description are
   triggered by reception of Resv Confirm, MUST to be executed at the
   reception of Resv message.

4.1 "MP to CP handover" - LSP Ownership Transfer From Management Plane
    To Control Plane

   Let's consider the case of a Data Plane connection between two nodes
   acting as ingress and egress for a LSP. Let's assume that Management
   Plane has the ownership and control of the LSP and that we want to
   hand it over to Control Plane.
   At the ingress node NMS initiates the transfer of LSP related
   information residing within Management Plane to GRSVP-TE records
   within Control Plane. We assume that this happens under operator or
   management application control and in particular that:

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

   Ingress node collects from MP all the LSP related information needed
   at Control Plane level. The way this operation is done and where such
   information is collected within MP is outside the scope of this memo.
   A relevant part of such information is represented by the LSP path,
   which has to be handed over to CP to be used by signaling entity to
   fill the Explicit Route Object (ERO) during setup.
   In order to support the MP to CP handover of LSP, the ERO object in
   the Path message MUST be filled with all the LSP relevant information
   down to the Label level.  That can be done by means of the object and
   procedures defined in [5].
   The precise filling of the ERO object is needed as we are assuming
   that the LSP already exists in the network and that every signaling
   relevant info about it is available and accessible to MP in terms of
   required LSP parameters to build a GRSVP-TE PATH message. After
   gathering all the LSP related information, the ingress node sends out
   a GRSVP-TE PATH message including the Administrative Status Object
   with HANDOVER flag set.

Caviglia et al.        Expires - December 2005               [Page 5]
                     draft-caviglia-mp2cpcp2mp-02            June 2005

   Upon reception of such GRSVP-TE PATH, a node MUST be able to
   understand that a MP to CP handover procedure is in progress by
   reading Handover flag.
   Either the ingress node of the LSP (upon request from MP) and
   intermediate and egress nodes (when 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
   requested or ongoing. The node assumes that a Data Plane resource
   related to the info carried in Path Message is already allocated and
   in place. The node SHOULD check however the consistence of the actual
   Data Plane status of such resource:

   - If the check goes OK, then a GRSVP-TE record for the LSP is
     created associating it to the corresponding Data Plane state. The
     node accepts all the LSP information carried in PATH (if the node
     is not ingress of the LSP, otherwise the information is sent from
     relevant MP entity) and stores it in Path State Block. After that,
     the procedure goes on as described below.

   - If the check goes NOT OK, that is actual Data Plane state for the
     indicated resource is different from the one indicated in the Path
     message, then:

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

        o GMPLS Control Plane state information about it is not accepted
          by the  handover destination entity

   In both cases, no operation is done over Data Plane. In case of
   positive check, no change is required at that level since the
   connection is already set up and in service. In case of negative
   check, a mismatch or some other error has occurred and no LSP control
   handover is possible. The procedure rolls back and information
   transfer process from MP to CP at ingress node of the LSP has to be
   fixed and reinitiated. A node participating in a MP to CP handover
   procedure MUST in fact keep track of the special 'handover' condition
   of the LSP involved, by retaining handover flag status within GRSVP-
   TE records.
   This is important because during handover procedure no other Data
   Plane, Control Plane or Management Plane action has to be taken on
   the LSP outside the control of the procedure itself. Such special
   state regarding the involved LSP has to be retained until the
   procedure itself has correctly ended.
   After propagating handover Path, a node MUST wait for a Resv message
   including Administrative Status Object with handover flag set. After
   receiving it, the actual migration of LSP information is complete.
   However, Handover flag is cleared in Path/Resv state block of the
   involved LSP, only by reception of ResvConfirm message (or Resv

Caviglia et al.        Expires - December 2005               [Page 6]
                     draft-caviglia-mp2cpcp2mp-02            June 2005

   message, if ResvConfirm is not supported). After the flag is cleared,
   the LSP is left completely under control of GRSVP- TE within Control
   Plane. This means that any memory about the former MP ownership of
   the LSP is lost.
   The following example covers all possible MP to CP Handover
   scenarios, either in case of success or failure. In the example we
   assume that Data Plane connection, whose control and control
   information has to be handed over from MP to CP, is TDM based (either
   SDH or SONET). A more generic case, where the Data Plane resource
   making up the LSP is not tied to a specific technology, can easily be
   derived from this one. The table refers to possible cases when a node
   at CP level has received LSP information provided by MP and verifies
   if handover is feasible.
   Let's consider a LSP over the network, connecting a ingress node I
   with an egress node E. Let's call timeslot A and B the Data Plane
   resources referred by control information involved in Handover in a
   given node traversed by the LSP. This means that Handover flagged
   signaling refers to A-B cross-connection over Data Plane.
   The ingress node initiates the procedure upon request from Management
   Plane. The way LSP related information is passed from MP to ingress
   node is outside the scope of this procedure description.
   Intermediates nodes and egress node receive the request for LSP
   adoption and the information needed for the operation from Handover
   flagged GRSVP-TE signaling.
   The symbol <----> in table below indicates that the two Timeslots
   involved in Data Plane cross-connection are actually cross-connected
   over Data Plane, hence Data Plane state corresponds to the indication
   provided by LSP data held by MP and in the process of being handed
   over to CP.

         |Actual Data|Control Plane  |Management Plane|Data Plane
         |Plane State|LSP data record|LSP data record |Resources check
   Case 1|  A<---->B |No info yet    |MP expects A-B  |OK to MP to CP
         |           |               |                |LSP handover
   Case 2|  A<---->C |No info yet    |MP expects A-B  |NOT OK for MP to
         |           |               |                |CP LSP handover

   Case 1:
   - LSP info from Management Plane to be used for LSP control hand
     over to GRSVP-TE matches Data Plane state in terms of involved
     resources
   - LSP data record is not owned yet by Control Plane, hence LSP
     control is still up to MP
   - Checks are OK, so GRSVP-TE state (related to involved LSP) is
     associated to Data Plane state after Handover flagged signaling
     flow (Path/Resv/Resv Confirm with Handover flag set) has ended.
   - At the end of signaling the LSP is completely under CP control.
   - No actions are taken in the Data Plane.

Caviglia et al.        Expires - December 2005               [Page 7]
                     draft-caviglia-mp2cpcp2mp-02            June 2005

   Case 2:
   - LSP info from Management Plane to be used for LSP control hand
     over to GRSVP-TE doesn't match Data Plane state in terms of
     involved resources.
   - Control Plane does not own LSP data record yet; hence LSP control
     is still up to MP.
   - Checks are NOT OK. A-B connection is not actually present over
     Data Plane and indicated 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 Path message.
   - A PathErr with Path State Removed flag set MUST be sent Upstream.
   - LSP ownership remains completely under MP control. Handover has
     failed.
   - No actions are taken in the Data Plane.

4.2 MP to CP Handover Procedure Failure Handling

   When a mismatch is detected between LSP information owned by MP (and
   going to be handed over to CP) and the actual Data Plane state
   corresponding to that LSP, actions have to be taken to roll back the
   LSP ownership handover correctly.
   If such mismatch is detected at LSP ingress node, the issue has to be

   resolved directly between ingress node and MP designed entity and
   this lies outside the scope of this memo. No Control plane signaling
   is involved yet at this stage.
   If the mismatch is detected at intermediate or egress nodes, when the
   LSP control information arrives at the node via handover flagged Path
   message, the node MUST reject it by issuing PathErr with Path State
   Removed towards the ingress node. In such a way the procedure is
   interrupted at that node, upstream nodes are informed and no changes
   are done over control and Data Plane. When a node receives PathErr
   with Path State Removed referred to a LSP, whose data record at CP
   has handover flag set (being in 'handover state'), it MUST clear such
   LSP data record and propagate the PathErr message upstream.
   No Data Plane actions have to be taken in this case as well.
   The same applies to PathTear message.

4.3 "CP to MP handover" - LSP Ownership Transfer From Control Plane To
    Management Plane

   Let's now consider the case of LSP Ownership Transfer From Control
   Plane To     Management Plane. The scenario is still a Data Plane
   connection between two     nodes acting as ingress and egress for a

Caviglia et al.        Expires - December 2005               [Page 8]
                     draft-caviglia-mp2cpcp2mp-02            June 2005

   LSP. But let's assume in this case     that Control Plane has the
   ownership and control of the LSP and that we want    to hand it over
   to Management Plane. This means that at the end of such    procedure,
   the Data Plane state related to that connection is still untouched,
   but the LSP related information record is no more owned by GRSVP-TE
   over Control Plane.
   In other words, after LSP ownership transfer from CP to MP, the LSP
   is no more under control of GRSVP-TE, which is no more able to "see"
   the LSP itself. This Section covers the procedure needed to manage
   this procedure as a dual, opposite procedure respect to the one
   described in previous section.
   The procedure is performed at a signaling level as described in
   Section 7.2.1 of the RFC 3473 [5].

   At LSP ingress node, relevant MP entity requests the ownership of the
   LSP, How this is done is outside the scope of memo. Ingress node and
   MP exchange the relevant information for this task and then
   propagates it over Control Plane by means of GRSVP-TE tear down
   signaling flow as detailed below.
   Ingress node MUST send out a Path Down message, with Handover and
   Reflect bits in Admin Status set. No action is taken over Data Plane
   and Control Plane keeps track of special handover state the LSP is
   in.
   Transit and Egress nodes, upon reception of such handover Path Down,
   propagate it without any Data Plane action, retaining the handover
   state information associated to the LSP. After that, every node waits
   until the Handover bit is received back in the Resv. Then a PathTear
   is issued and the whole LSP information record is cleared from GRSVP-
   TE data structures. In other words, a normal LSP tear down signaling
   is exchanged between nodes traversed by the LSP, but handover flag
   set in Path Down message indicates that no Data Plane action has to
   correspond to Control Plane signaling. At the end of handover tear
   down signaling flow, the LSP is released from Control Plane point of
   view, but its Data Plane state is still unmodified and it is now
   owned and controllable by MP.

4.4 CP to MP Handover Procedure Failure Handling

   Failures during CP to MP handover procedure MUST be managed at
   signaling level as in normal LSP tear down procedure. The only
   difference is the handover flag set in Administrative Status Object
   inside Path Down message which MUST be read by receiving node and
   imposes that no action has to be made over Data Plane resource whose
   corresponding Control Plane record is involved in handover procedure.

Caviglia et al.        Expires - December 2005               [Page 9]
                     draft-caviglia-mp2cpcp2mp-02            June 2005

5. RSVP Message Formats

   This memo does not introduce any modification in RSVP messages.

5.1 Object Modification

   This memo introduces a new flag into the Administrative Status
   object.
   The Admin_Status Object is defined in RFC 3473 [5].
   This document uses the H-bit of the Admin_Status object. The bit is
   bit number (TBD by IANA).

   Handover signaling (H): 1 bit

   When set, indicates that a Handover procedure for the transfer of LSP
   ownership between Management and Control Planes is ongoing .

6. Security Considerations

   The procedures described in this document rely completely on GRSVP-TE
   messages and mechanism. The use of Handover Flag set in Admin Status
   Object basically informs the receiving entity that no operations are
   to be done over Data Plane as consequence of such special signaling
   flow. Using specially flagged signaling messages we want to limit the
   function of setup and tear down messages to Control Plane, making
   them not effective over related Data Plane resource usage. So, no
   additional or special issues are arisen by adopting this procedure,
   that aren't already brought up by the use of the same messages,
   without handover flag setting, for LSP control. For GRSVP-TE Security
   please refer to [3].

7. IANA Consideration

   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.

Caviglia et al.        Expires - December 2005              [Page 10]
                     draft-caviglia-mp2cpcp2mp-02            June 2005

8. 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

   [3] Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax
   Specifications: ABNF", RFC 2234, Internet Mail Consortium and Demon
   Internet Ltd., November 1997

   [4] L. Berger (Ed.) ææGeneralized Multi-Protocol Label Switching
   (GMPLS) Signaling Functional DescriptionÆÆ, RFC 3471, January 2003

   [5] L. Berger (Ed.) ææGeneralized Multi-Protocol Label Switching
   (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering
   (RSVP-TE) ExtensionsÆÆ, RFC 3473, January 2003

   [6] Zamfir, A., " Component Link Recording and Resource Control for

   GMPLS Link Bundles", draft-zamfir-explicit-resource-control-bundle-
   03, February 2004 - work in progress.

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

9. Acknowledgments

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

Author's Addresses

   Diego Caviglia
   Marconi
   Via A. Negrone 1/A
   Genova-Sestri Ponente, Italy
   Phone: +390106003738
   Email: [email-masked]

   Dino Bramanti
   Marconi
   Via Moruzzi 1

Caviglia et al.        Expires - December 2005              [Page 11]
                     draft-caviglia-mp2cpcp2mp-02            June 2005

   C/O Area Ricerca CNR
   Pisa, Italy
   Email: [email-masked]

   Nicola Ciulli
   NextWorks
   Corso Italia 116
   56125 Pisa, Italy
   Email: [email-masked]

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.

   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 ietf-
   [email-masked].

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 - December 2005              [Page 12]
                     draft-caviglia-mp2cpcp2mp-02            June 2005

Caviglia et al.        Expires - December 2005              [Page 13]

---

From: [email-masked]
Date: Wed, 20 Jul 2005 13:23:42 +0200

diego

as part of the motivation section of this document it would be indeed interesting to be much more explicit about the CP->MP handover purpose(s) before progressing on this part of the mechanism

- d.

"Diego Caviglia" <[email-masked]>
Sent by: [email-masked]
07/20/2005 11:37 ZE2

To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
cc: "ccamp" <[email-masked]>, "gnewsome" <[email-masked]>, "adrian" <[email-masked]>
bcc:
Subject: RE: Moving LSP ownership between control plane and management plane

Dimitri,

Diego

diego -

no -

-dimitri.

---

From: "Stephen Shew" <[email-masked]>
Date: Wed, 20 Jul 2005 08:25:18 -0400

See below.

> Sent: Wednesday, July 20, 2005 07:33
> To: Shew, Stephen [CAR:QT30:EXCH]
> Cc: [email-masked]
> Subject: Re:
> 
> 
> 
> Hi Stephen,
>             my answers in line.
> 
> Regards
> 
> Diego
> 
> 
> 
> "Stephen Shew" <[email-masked]>@ops.ietf.org on 20/07/2005 12.22.49
> 
> To:    "\"ccamp\" <ccamp"
> cc:
> Subject:
> Diego, my suggestion for this draft is that it separate the 
> mechanism (not setting the cross connects specified in an 
> ERO), from the reason for doing so.  This is because the 
> mechanism could be used for more than just CP<->MP handoff. 
> [dc] Hmmm I've defined that application mainly for two reason:
> 1     up to my knowledge that is the 'killer application' for 
> this kind of
> protocol modification
> 2     my understanding of CCAMP is that a good motivation needs to be
> provided to modify GRSVP-TE and this leads to point 1

I have no issue with the motivation.  I just think there are more
scenarios for creating control plane state for an existing cross
connection.

> If you do this then the bit should be renamed something like 
> "cross-connection exists" and if set, then the signaling 
> protocol does not tell the cross connection to set/release 
> it. [dc] That is how it works apart for the name of the flag.

I realize that. What I'm suggesting is that the name reflect an action
rather than one of several possible purposes.

> Did you consider a generalization of this where in the ERO, 
> each element has this type of flag?  If so, you could use the 
> mechanism to say replace two LSPs where the tail of one is 
> next to the head of the other, with a single LSP.  The action 
> would be to signal an ERO containing connection details of 
> each LSP that have the flag on, and where they join, have the 
> flag off. [dc] If I've understood corretly your point, what 
> you are saying is a little bir different from what the ID 
> proposes.  I mean in your exaple you have two different LSPs 
> that already have some control plane information associated 
> with them and you want to splice them together.  In this case 
> you have to replace the CP information while the ID proposes 
> to add CP information to a XC that don't have it.  Do you 
> agree with that?

The suggestion was that there are other scenarios in which establishment
of new LSP state for an existing cross connection is useful.  In the
MP->CP case, the MP initially holds state for the connection and before
the action is completed, both MP and CP hold state.  In the two LSP
example above, two entities in the CP hold state about the same
connection.  I see these two cases as similar in that the general case
is about multiple entities holding state for the same resource.

> Stephen
> > Behalf Of Diego Caviglia
> > Sent: Wednesday, July 20, 2005 05:44
> > To: [email-masked]
> > Cc: ""Dimitri.Papadimitriou" <Dimitri.Papadimitriou"; 
> "ccamp" <ccamp; 
> > "gnewsome" <gnewsome; "adrian" <adrian
> > Sorry for this but may be not all have read the ID, I hope 
> that having 
> > the text help the discussion.
> >
> > Regards
> >
> > Diego
> >
> >
> >
> >
> >    Network Working Group
> >    Internet Draft
> > Diego Caviglia
> <snip>

---

From: "Diego Caviglia" <[email-masked]>
Date: Wed, 20 Jul 2005 16:48:14 +0200

In line

Regards

Diego

"Stephen Shew" <[email-masked]> on 20/07/2005 14.25.18

[CUT]

I have no issue with the motivation.  I just think there are more
scenarios for creating control plane state for an existing cross
connection.
[dc] Yes I agree, do you have any suggestion on other scenarios?

I realize that. What I'm suggesting is that the name reflect an action
rather than one of several possible purposes.
[dc] No problem with this, actually the original name of the flag was Fake
flag indicating that creation and deletion are not for real.
If there are no objection on this we can change the flag name.

[CUT]

[dc] Yes agreed

---

From: "Dino Bramanti" <[email-masked]>
Date: Wed, 20 Jul 2005 17:39:41 +0200

Dimitri,

as Diego says in his post, the main use for the procedure defined in our ID
is for MP->CP handover.
This at least could be its immediate possible use and surely it is the
reason why we started thinking
about a similar mechanism within CP. But we have proposed the complete
procedure including the reverse CP->MP handover for several reasons.
The first one is related to the need of reverting back what MP-CP procedure
does in case of some kind of failure during its action. In addition, the
possibility of doing a CP->MP handover of LSP, leaving untouched
corresponding data plane state, could be useful for specific needs. An
example could be a Control Plane software upgrade to be performed on
network elements that are in service and carrying traffic over data plane.
In such a case it could be possible to perform a CP->MP handover of a
number of LSP, transfering their ownership to MP for the time required.

Furthermore, taking Stephen's suggestion about it and looking at the
proposed mechanism (i.e. handover flag usage within GRSVPTE signaling flow)
as a general way to act on CP state without affecting data plane state, the
need for a two-way procedure is required to provide it with maximum
flexibility.

Thank you
dino

>as part of the motivation section of this document it would be indeed
interesting to be much more explicit about the CP->MP >handover purpose(s)
before progressing on this part of the mechanism

---

From: "MEURIC Julien RD-CORE-LAN" <[email-masked]>
Date: Mon, 25 Jul 2005 18:18:11 +0200

Hello Diego, Adrian and all.

In my view, I feel that moving LSP ownership between MP and CP are very
useful functions for a carrier operational network, whether it be for
migration to GMPLS or for network maintenance.
As far as I understand, the I-D is a proposal for the signalling part
and does not pretend solving every associated issues. Some work will
probably be needed to implement the whole process, but this part looks
interesting to me.

I would be glad to discuss further this matter next week in Paris.

Regards

Julien 

Julien Meuric
France Telecom
Research & Development
Core Network
2, avenue Pierre Marzin
22307 Lannion Cedex - France
Tel : + 33 (0)2 96 05 28 28
Fax : + 33 (0)2 96 05 12 52
http://www.francetelecom.com/rd/

-----Original Message-----

Hi Geroge,

There are already RFC ID that provide tools to signal LSP with ERO
filled
up to the Label level and of course this can be done only via
management, I
don't remeber any objections on that due to NMS impact.

I'd like to discuss here (I mean in the CCAMP ML) about the ID, that is,
if
it useful and if could work and not about the difficulties it implies
for
the NMS.

Regards

Diego

Adrian, Dino, etc.,

Regards

             George

management
>>contribution addresses SP24 (PC ? SPC) of G.7713. It proposes to
extend
>>actions required before signalling is involved. The group noted that
the
>>- Naming of transport resources to the control plane.  Before a call
can
>>- Resource state while under dual CP and MP views.  After resources
are
>>are allocated, distributed control plane functions need to be
associated
> be deployed, we can assume this operation and move on to the
discussion
in
>>subsequent recovery.  Connection control procedures might be the same
in
migration.

---

From: "Diego Caviglia" <[email-masked]>
Date: Tue, 26 Jul 2005 10:43:01 +0200

Hi Julien,
           I'll be in Paris next week and will be a pleasure to discuss
this with you.

Regards

Diego

"MEURIC Julien RD-CORE-LAN" <[email-masked]> on 25/07/2005
18.18.11

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

Regards

Julien

Julien Meuric
France Telecom
Research & Development
Core Network
2, avenue Pierre Marzin

-----Original Message-----

Hi Geroge,

Regards

Diego

Adrian, Dino, etc.,

Regards

             George

management
extend
the
can
are
associated
discussion
in
in
migration.