Re: [CCAMP] The description of Path Key retaining time in RFC5553

[Fatai Zhang <[e-mail]>]

Hi George,

Apart from the difference between "CACHE" and "SAVE", it seems that you don't see any problem. 

In addition, you can find a place to store so complex 5 tuplet information, why there is no place to store simple Path Key? 

Please make our logic more logical. 


Best Regards

Fatai


-----Original Message-----
From: George Swallow (swallow) [mailto:[e-mail]] 
Sent: Wednesday, November 13, 2013 2:44 AM
To: Fatai Zhang; Zafar Ali (zali); Zhangxian (Xian)
Cc: [e-mail]; George Swallow (swallow)
Subject: Re: [CCAMP] The description of Path Key retaining time in RFC5553

Fatai -

If a PCE is saving state, then in what way is it "stateless".  The text
you have below and along with Zafar's quote (from RFC5520) is of a PCE
that CACHEs the result (ERO segment) of a constrained path selection along
with the key it handed out.  As a path is signaled an LSR or (or perhaps
several LSRs) may contact PCEs using a path key to retrieve the path in
order to extend or complete the ERO.

But the PCE merely caches.  The only state that is saved for the life of
the LSP is at the LSR.

George

On 11/11/13 9:09 PM, "Fatai Zhang" <[e-mail]> wrote:

>Hi Zafar,
>
>It does not matter what it is.
>
>Do you see any problem for an element (a stateless PCE or NMS or even a
>node) to store path key information?
>
>Please don't argue scaliblity issue because you can see even a GMPLS node
>can store lots of informaiton.
>
>
>
>Best Regards
>
>Fatai
>
>
>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On Behalf Of
>Zafar Ali (zali)
>Sent: Saturday, November 09, 2013 11:58 AM
>To: Zhangxian (Xian)
>Cc: [e-mail]
>Subject: Re: [CCAMP] The description of Path Key retaining time in RFC5553
>
>Hi Zhang: 
>
>Section 2.1 from RFC5553 state: "It is RECOMMENDED for a PCE to store the
>PKS for a period of 10 minutes." Furthermore, please note that 16 bit path
>keys are used as reuse of the path key is assumed.
>
>
>The bottom line is that in your draft the PCE needs to remember the (path
>key, path info) "states" for "indefinite" time. If you like we call such
>PCE "path-stateful PCE" but it is stateful. Also, the solution is not
>scalable as a PCE can only hold 64K of (path key, path info) states. Such
>limitations and requirements need to be clearly stated in the draft.
>
>Thanks
>
>Regards Š Zafar
>
>
>-----Original Message-----
>From: "Zhangxian   (Xian)" <[e-mail]>
>Date: Thursday, November 7, 2013 11:24 AM
>To: zali <[e-mail]>
>Cc: "[e-mail]" <[e-mail]>
>Subject: The description of Path Key retaining time in RFC5553
>
>>Hi, all,
>>
>>  The following is the piece of information that i mentioned already
>>require retaining the Path key information for the lifetime of LSP.
>>
>>Section 3.2 from RFC5553
>>"
>>.......
>>On a Path message, the PKS SHOULD identify the LSR replacing the CPS and
>>provide a Path Key that can be used to expand  the path segment.  In the
>>latter case, the Path Key and its expansion SHOULD be retained by the LSR
>>that performs the substitution for at least the lifetime of the LSP.  In
>>both cases, the expansion of the PKS SHOULD be made available to
>>diagnostic tools under the control of local policy.
>>"
>>
>>My understanding of the stateful PCE (from PCE WG) is to have LSP-DB
>>documenting information such as the identifiers (the 5-tuple), route, bw
>>information etc. So I do not think our extensions defined in
>>http://tools.ietf.org/html/draft-zhang-ccamp-route-exclusion-pathkey-00
>>incur any new additional requirements. Please review our draft and let us
>>know what you think.
>>
>>Cheers,
>>Xian
>
>_______________________________________________
>CCAMP mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ccamp
>_______________________________________________
>CCAMP mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ccamp