Subject: A nerw ID is available on the repository draft-caviglia-ccamp-pc-and-sc-reqs-00

From: "Diego Caviglia" <[email-masked]>
Date: Wed, 24 May 2006 09:48:25 +0200

A new ID is available on the ID repository
http://www.ietf.org/internet-drafts/draft-caviglia-ccamp-pc-and-sc-reqs-00.txt.

The ID states some basic requrements for the possibility of turning a
Permanent Connection (PC) into a Soft Permanent Connection (SPC) and vice
versa, without actually affecting Data Plane traffic, no solutions are
proposed in the ID.

Abstract

   From a Carrier perspective, the possibility of turning a Permanent
   Connection (PC) into a Soft Permanent Connection (SPC) and vice
   versa, without actually affecting Data Plane traffic being carried
   over it, is a valuable option. In other terms, such operation can be
   seen as a way of transferring the ownership and control of an
   existing and in-use Data Plane connection between the Management
   Plane and the Control Plane, leaving its Data Plane state untouched.
   This memo sets out the requirements for such procedures within a
   Generalized Multiprotocol Label Switching (GMPLS) network.

Comments and suggestions are very welcome sxpecially from the carrier
community.

Regards

Diego

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 25 May 2006 18:53:12 +0100

Hi Diego,

Thanks for putting this I-D together. I think it gives a much clearer 
picture of what you are trying to achieve with your discussion of moving 
control of an LSP between the management plane and the control plane.

This seems like a reasonable set of requirements to me, and I would like to 
see some discussion from folk on whether they think this is valuable work, 
and whether we should start to look for protocol solutions.

Thanks,
Adrian

----- Original Message ----- 
From: "Diego Caviglia" <[email-masked]>
To: <[email-masked]>
Cc: "Dan Li <danli" <[email-masked]>; "Dino Bramanti" 
<[email-masked]>
Sent: Wednesday, May 24, 2006 8:48 AM
Subject: A nerw ID is available on the repository 
draft-caviglia-ccamp-pc-and-sc-reqs-00

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 31 May 2006 18:13:53 +0100

Hi Walter,

Thanks for your thoughts.

May I restate them to make sure that I understand?

> While I think these requirements are real, I can not imagine that they
> can be solved by some protocol extensions.

If I am interpretting you correctly, you are saying that you agree with the 
requirements. This means that *if* they can be solved, you would be quite 
pleased. And even if they could only be solved in certain control 
situations, you would also think that a good thing.

On the other hand, you are skeptical that a solution can be developed. 
Presumably, this means that you would not want to spend your time attempting 
to develop one, or see the WG expend much bandwidth on trying to find a way 
to meet the requirements. But I don't suppose you would object if the 
authors of this I-D spent their own time trying to hatch a solution and then 
brought it to the working group for discussion.

> One reason is, as it is stated in the I_D, that "ownership by the 
> Management
> and Control Planes is strictly an implementation issue", which we can not
> solve by a protocol alone.

Hmmm. Yeah I guess it could be a problem if a device determined that it 
would not allow resources to be exchanged between the two planes. Handling 
(or, more precisely, not handling) NEs that do not support these funcitons 
certainly has to be discussed. I suppose there are two situations:
1. As you describe, the LSP cannot be shifted. I.e. the LSR understands
  the request but is unable or unwilling to comply.
2. The LSR does not understand the request. I.e. it has not been
  upgraded to handle the protocol solution.

I think this is actually business as usual for protocol work, isn't it?

> Secondly, the MP and CP typically store additional data associated with 
> the
> connection, which is implementation specific, but needs also appropriate
> conversion, or the conversion must at least ensure data integrity.

I'd be intrigued to know what additional informaiton a standard GMPLS 
control plane is going to store over and above what is signaled by the 
protocol. So the problem you describe is lopsided - if the MP and CP are 
capable of storing the additional information then I think there is no issue 
(and presumably everything is the same implementation-specific stuff). But 
if there are differences in implmentations in the CP, then they must be 
running some common set of protocol extensions and it is this that needs to 
be converted to/from the MP.

Note that if the MP offers the ability to configure things on an NE that 
cannot be carried in signaling then those things cannot bve carried in 
signaling, period. That is, you cannot consider provisioning an LSP in the 
CP at all if you need to carry this information. Fortunately, we are not 
having a discussion on the relative merits of using a control plane - the 
situation we are examining is one where the operator (the customer!) has 
decided to move ownership of an LSP between planes, and wants to know how to 
do it. That means that the operator has already accepted that the LSP can be 
managed by both planes and wishes to make the transfer without turning the 
service down.

> Finally, need to look, what is convertible at all. E.g., the MP may have
> implemented certain broadcast or multicast connections, or special 
> protection
> schemes, which are not (yet) supported by the CP.

Yes, there is the possiblity that certain services in the MP cannot be 
achieved in the CP (although it would be interesting to discuss which, 
because if there is a need, the control plane is surely in need of 
enhancement). So you are right, there may be some LSPs that cannot be 
migrated in this way. But what about those that can? Do you think we should 
at least consider these requirements for those LSPs that can be migrated?

Many thanks,
Adrian

---

From: WALTER ROTHKEGEL <[email-masked]>
Date: Wed, 31 May 2006 18:00:13 +0200

Adrian,

some thoughts:

One reason is, as it is stated in the I_D, that "ownership by the Management
and Control Planes is strictly an implementation issue", which we can not
solve by a protocol alone.

Secondly, the MP and CP typically store additional data associated with the
connection, which is implementation specific, but needs also appropriate
conversion, or the conversion must at least ensure data integrity.

Finally, need to look, what is convertible at all. E.g., the MP may have
implemented certain broadcast or multicast connections, or special protection
schemes, which are not (yet) supported by the CP.

Regards

Walter

-- 
________________________________________________________________________
Walter Rothkegel, Lucent Technologies Network Systems GmbH, Dept. O-SE
Thurn-und-Taxis-Str. 10-14, 90411 Nuernberg, Germany
Phone: +49 911 526-4084      Fax:   +49 911 526-6299
mailto:[email-masked]

---

From: [email-masked]
Date: Wed, 31 May 2006 20:37:45 +0200

adrian - what does the term "broadcast" connection refers to in the below 
message ?

afaik in the context of MPLS-TE/GMPLS: p2p, and p2mp TE LSPs are 
considered isn'it ?

"Adrian Farrel" <[email-masked]>
Sent by: [email-masked]
31/05/2006 19:13
Please respond to "Adrian Farrel"
 
        To:     "WALTER ROTHKEGEL" <[email-masked]>
        cc:     <[email-masked]>, "Diego Caviglia" 
<[email-masked]>, "Dan Li <danli", "Dino Bramanti" 
<[email-masked]>
        Subject:        Re: A nerw ID is available on the repository 
draft-caviglia-ccamp-pc-and-sc-reqs-00

Hi Walter,

> can be solved by some protocol extensions.

If I am interpretting you correctly, you are saying that you agree with 
the 
requirements. This means that *if* they can be solved, you would be quite 
pleased. And even if they could only be solved in certain control 
situations, you would also think that a good thing.

On the other hand, you are skeptical that a solution can be developed. 
Presumably, this means that you would not want to spend your time 
attempting 
to develop one, or see the WG expend much bandwidth on trying to find a 
way 
to meet the requirements. But I don't suppose you would object if the 
authors of this I-D spent their own time trying to hatch a solution and 
then 
brought it to the working group for discussion.

capable of storing the additional information then I think there is no 
issue 

if there are differences in implmentations in the CP, then they must be 
running some common set of protocol extensions and it is this that needs 
to 
be converted to/from the MP.

CP at all if you need to carry this information. Fortunately, we are not 
having a discussion on the relative merits of using a control plane - the 
situation we are examining is one where the operator (the customer!) has 
decided to move ownership of an LSP between planes, and wants to know how 
to 
do it. That means that the operator has already accepted that the LSP can 
be 
managed by both planes and wishes to make the transfer without turning the 

service down.

migrated in this way. But what about those that can? Do you think we 
should 

Many thanks,
Adrian

---

From: [email-masked]
Date: Wed, 31 May 2006 20:44:54 +0200

agreed -

question: in case of move CP->MP who guarantees that the CP at state [b] 
retrieves its states it had at [a] e.g.

MP->CP[a]->MP->CP[b]? 

do we need a specific requirement for this case ?

25/05/2006 19:53
 
        To:     <[email-masked]>, "Diego Caviglia" 
<[email-masked]>
        cc:     "Dan Li <danli", "Dino Bramanti" 
<[email-masked]>
        Subject:        Re: A nerw ID is available on the repository 
draft-caviglia-ccamp-pc-and-sc-reqs-00

Hi Diego,

This seems like a reasonable set of requirements to me, and I would like 
to 
see some discussion from folk on whether they think this is valuable work, 

Thanks,
Adrian

----- Original Message ----- 
From: "Diego Caviglia" <[email-masked]>
To: <[email-masked]>
Cc: "Dan Li <danli" <[email-masked]>; "Dino Bramanti" 

>A new ID is available on the ID repository
http://www.ietf.org/internet-drafts/draft-caviglia-ccamp-pc-and-sc-reqs-00.txt
.

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 1 Jun 2006 00:15:04 +0100

Hi Dimitri,

> adrian - what does the term "broadcast" connection refers to in the below

Well, Walter is the best person to ask since it was his message.

> afaik in the context of MPLS-TE/GMPLS: p2p, and p2mp TE LSPs are

Some parsing problems on your sentence, but I think you are saying what I 
thought when I read this.

Effectively, I assumed that "broadcast connection" and "multicast 
connection" were intended to be synonyms for P2MP LSP (possibly with slight 
differences in usage maybe through label stacking).

Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 1 Jun 2006 00:18:10 +0100

Interesting question.

It would certainly be the case that the picture you draw could arise. I 
guess we would describe this in terms of SPCs. Is it necessary that 
identical state is held at [a] and [b]. In particular, the question of 
Session ID and LSP ID spring to mind.

Yes, we need clear requirements for this type of situation.  Want to suggest 
some?

Adrian

----- Original Message ----- 
From: <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>; "Diego Caviglia" <[email-masked]>; 
"Dino Bramanti" <[email-masked]>
Sent: Wednesday, May 31, 2006 7:44 PM
Subject: Re: A nerw ID is available on the repository 
draft-caviglia-ccamp-pc-and-sc-reqs-00