[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
pandian
i simply referred to the case where
MP -> CP[t(i),s[i],LSP[i]] -> MP -> CP[t(j),s[j],LSP[j]]
that t(j) > t(i) represents a temporal move
that s(i) =/= s(j) represents a spatial move
LSP[i] =/= LSP[j] represents a state modification
it seems to me that (with time unit being refresh time) we've four cases,
with each time a subcase depending on either a) LSP[i] = LSP[j] for all s.
or b) LSP[i] =/= LSP[j] but when a change is performed for a given
parameter describing the PSB/RSB it must be performed at each hop i.e. for
all s.:
1. t(i) = t(j), in case s(i) = s(j) nothing changes
2. t(i) = t(j), in case s(i) =/= s(j) - spatial move -
3. t(i) > t(j), in case s(i) = s(j) *** this is for me the only case
covered with the subcase a) ***
4. t(i) > t(j), in case s(i) =/= s(j) - spatial move -
=> do we want sub-case 3.b ?
how to cover case 2. and 4 ?
the point is that i still have to check how this would work during the
transit period b/w successive intervals ](n-1) R, n R], R = Refresh int. L
= cleanup, with L >= N x R) because you must ensure that the states that
are taken over by the MP are consistent (during the move CP->MP) before
being capable to be released to the control plane (during the move MP ->
CP)
"Pandian, Vijay" <Vijay.Pandian@sycamorenet.com>
02/06/2006 19:42
To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, Adrian Farrel
<adrian@olddog.co.uk>
cc: ccamp <ccamp@ops.ietf.org>, Diego Caviglia
<Diego.Caviglia@marconi.com>
Subject: RE: A new ID is available on the repository
draft-caviglia-ccamp- pc-and-sc-reqs-00
Dimitri,
Could you please give some additional detail on the issue.
The original scenario is as follows:
MP -> CP[a] -> MP -> CP[b]
What exactly is this scenario illustrating:
a) Is it illustrating a scenario where an LSP was transferred to the CP in
three steps: first from MP to CP (i.e.., MP -> CP[a] part), secondly, at
some later point in time, the same LSP is transferred back to MP for what
ever reason (i.e., the CP[a] -> MP part) and finally at some later point
in
time the same LSP is transferred back from MP to CP (MP -> CP[b] part).
b) or is it like what Adrian has interpreted: i.e., there are 4 LSR's
involved in this scenario. But then what exactly is the problem? Is it the
case that the LSP is partially converted to CP at two of the LSR's and MP
still owns the LSP at the other two LSRs?
c) or is it some thing else.
My interpretation of your issue was scenario (a). If that is the case, I
don't see need for extra requirements.
On the other hand, if it is (b), I am not sure how would this be possible
if
we do the protocol right.
If (c), please provide some additional detail on the scenario.
Thanks and best regards,
Vijay
-----Original Message-----
From: Dimitri.Papadimitriou@alcatel.be
[mailto:Dimitri.Papadimitriou@alcatel.be]
Sent: Friday, June 02, 2006 9:57 AM
To: Adrian Farrel
Cc: ccamp; Diego Caviglia; Pandian, Vijay
Subject: Re: A new ID is available on the repository
draft-caviglia-ccamp- pc-and-sc-reqs-00
hi adrian
CP[I] is to be complemented with I including values from the set
{t,s[i],lsp[i]}
t = time
s[i] = rsvp_instance
lsp[i] = values associated to the P/RSB indexed by 5_tuple[i]
thanks,
- dimitri.
"Adrian Farrel" <adrian@olddog.co.uk>
Sent by: owner-ccamp@ops.ietf.org
01/06/2006 13:25
Please respond to "Adrian Farrel"
To: <Vijay.Pandian@sycamorenet.com>, "Diego Caviglia"
<Diego.Caviglia@marconi.com>
cc: 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,
I read Dimitri's comments as being spatial not temporal.
I.e. he drew a figure showing four LSRs.
Dimitri?
Cheers,
Adrian
----- Original Message -----
From: "Diego Caviglia" <Diego.Caviglia@marconi.com>
To: <Vijay.Pandian@sycamorenet.com>
Cc: """'Adrian Farrel'" <adrian"" <adrian@olddog.co.uk>;
"Dimitri.Papadimitriou" <Dimitri.Papadimitriou@alcatel.be>; "ccamp"
<ccamp@ops.ietf.org>; "Dino Bramanti <Dino.Bramanti"
<Dino.Bramanti@marconi.com>; "Dan Li <danli" <danli@huawei.com>
Sent: Thursday, June 01, 2006 8:20 AM
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.
>
> 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]
>
> 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
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>
>
>
>
>
>
>
>
>
>