[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: A new ID is available on the repository draft-caviglia-ccamp-pc-and-sc-reqs-00
Hi Diego, hi all.
I also think the PC<->SPC conversion is a useful function for transport
networks, especially for operators who were used to doing everything
from the MP.
About the 3-migration scenario, I do not see the need for having CP[b] =
CP[a]: internal CP information may be different between both states but,
provided the data plane remains the same, this is not an issue. Of
course, before committing any ownership transfer and removing
information, the new state must be ackowleged by each involved device.
This is true for a simple LSP but also for a group of LSPs, e.g. in case
of transfering a 1+1 protected connection.
Regards,
Julien
-----Original Message-----
From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On
Behalf Of Diego Caviglia
Hi Dimitri,
Quoted from your e-mail
"[dp] meaning that you must be ensure that b/f transfer the state is
completely in-sync among all nodes used to be traversed by the LSP"
Now I see your point, I think that we can add a req to cover your
concern.
Regards
Diego
Dimitri.Papadimitriou@alcatel.be on 03/06/2006 10.42.57
To: "Diego Caviglia" <Diego.Caviglia@marconi.com>
cc: Dimitri.Papadimitriou@alcatel.be, "ccamp" <ccamp@ops.ietf.org>,
Dino
Bramanti <Dino.Bramanti@marconi.com>, "Adrian Farrel"
<adrian@olddog.co.uk>
Subject: RE: A new ID is available on the repository
draft-caviglia-ccamp- pc-and-sc-reqs-00
hi diego - see inline
"Diego Caviglia" <Diego.Caviglia@marconi.com>
Sent by: owner-ccamp@ops.ietf.org
01/06/2006 09:20
To: Vijay.Pandian@sycamorenet.com
cc: "\"\"'Adrian Farrel'\" <adrian\"", Dimitri
PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "ccamp" <ccamp@ops.ietf.org>, "Dino
Bramanti <Dino.Bramanti", "Dan Li <danli"
Subject: RE: A new ID is available on the repository
draft-caviglia-ccamp- pc-and-sc-reqs-00
Hi Vijay,
some answers in line.
Regards
Diego
"Pandian, Vijay" <Vijay.Pandian@sycamorenet.com>@ops.ietf.org on
01/06/2006
04.34.12
Sent by: owner-ccamp@ops.ietf.org
To: "'Adrian Farrel'" <adrian@olddog.co.uk>,
Dimitri.Papadimitriou@alcatel.be
cc: ccamp@ops.ietf.org, Diego Caviglia <Diego.Caviglia@marconi.com>,
Dino Bramanti <Dino.Bramanti@marconi.com>
Subject: RE: A new ID is available on the repository
draft-caviglia-ccamp- pc-and-sc-reqs-00
Adrian and Dimitri,
Not sure why we need extra requirements to handle this case. Also not
sure
why CP needs to guarantee identical states at [a] and [b]. May be I am
not
understanding the case that is being pictured here.
The way I read the requirements, once the control is transferred to MP
(i.e., CP[a] -> MP), CP should forget everything about this LSP, Isn't
it?
[dc] That is the idea.
[dp] meaning that you must be ensure that b/f transfer the state is
completely in-sync among all nodes used to be traversed by the LSP
If this is true, then MP -> CP[b] should be treated as the ONLY general
case
of MP -> CP conversion, right?
[dc] Yes, unless Dimitri calirifies better what he intend with state[a]
and
state[b]
[dp] see my previous post - note the above has an impact on the present
point
Regards,
Vijay
-----Original Message-----
From: Adrian Farrel [mailto:adrian@olddog.co.uk]
Sent: Wednesday, May 31, 2006 7:18 PM
To: Dimitri.Papadimitriou@alcatel.be
Cc: ccamp@ops.ietf.org; Diego Caviglia; Dino Bramanti
Subject: Re: A new ID is available on the repository
draft-caviglia-ccamp-pc-and-sc-reqs-00
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: <Dimitri.Papadimitriou@alcatel.be>
To: "Adrian Farrel" <adrian@olddog.co.uk>
Cc: <ccamp@ops.ietf.org>; "Diego Caviglia" <Diego.Caviglia@marconi.com>;
"Dino Bramanti" <Dino.Bramanti@marconi.com>
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
> 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.t
xt
> .
>>
>> 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
>>
>>
>>
>>
>>
>>
>
>
>
>
>
>
>
>