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

[Dimitri.Papadimitriou@alcatel.be]

hi - this one of the case to be covered - now i didn't yet propose any 
specific behaviour - 
i did just mention that the problem exist and should be considered





lidan 37133 <danli@huawei.com>
01/06/2006 16:49
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     Adrian Farrel <adrian@olddog.co.uk>, ccamp@ops.ietf.org, 
Diego Caviglia <Diego.Caviglia@marconi.com>, Dino Bramanti 
<Dino.Bramanti@marconi.com>
        Subject:        回复:Re: A nerw ID is available on the repository 
draft-caviglia-ccamp-pc-and-sc-reqs-00


Hi Dimitri,

If I understand correctly, you have drawn a scenario like this:
Step 1: A PC is migrated to a SC;
Step 2: Then the SC is migrated to a PC;
Step 3: Then the PC is migrated to a SC again;

So how to guarantee the state of a SC at the step 3 is same as the state 
of a SC at the step 1, am I right?
 
I think we don't need to keep the same state of the SC at different steps, 
for example, the session ID of a SC at step 1 MAY be different with the 
session ID of a SC at step 3.

I greatly appreciate your comments, hope you can help with this work.

Best regards,

Dan

----- 原邮件 -----
发件人: Dimitri.Papadimitriou@alcatel.be
日期: 星期四, 六月 1日, 2006 上午2:44
主题: Re: A nerw ID is available on the repository 
draft-caviglia-ccamp-pc-and-sc-reqs-00

> 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 ?
> 
> 
> 
> 
> 
> 
> "Adrian Farrel" <adrian@olddog.co.uk>
> Sent by: owner-ccamp@ops.ietf.org
> 25/05/2006 19:53
> Please respond to "Adrian Farrel"
> 
>        To:     <ccamp@ops.ietf.org>, "Diego Caviglia" 
> <Diego.Caviglia@marconi.com>
>        cc:     "Dan Li <danli", "Dino Bramanti" 
> <Dino.Bramanti@marconi.com>
>        Subject:        Re: A nerw ID is available on the 
> repository 
> draft-caviglia-ccamp-pc-and-sc-reqs-00
> 
> 
> 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" <Diego.Caviglia@marconi.com>
> To: <ccamp@ops.ietf.org>
> Cc: "Dan Li <danli" <danli@huawei.com>; "Dino Bramanti" 
> <Dino.Bramanti@marconi.com>
> 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
> 
> 
> >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
> >
> >
> >
> >
> >
> > 
> 
> 
> 
> 
> 
> 
>