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

["Zafar Ali (zali)" <[e-mail]>]

Hi Fatai- 

Please see in-line.

Thanks

Regards ... Zafar


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

There is a BIG difference than the words may suggest. Both from protocol
view point as well as PCE implementation view point.
- From protocol view point, in addition to other issues emailed earlier, I
also sent you/ Xian scalability concerns and your solution simply does not
work. 
- From implementation point of view, the differences are as follows: a PCE
that caches the (path key, path info) state, does not need to worry high
availability cases. Your solution requires a PCE to make (path key, path
info) persistence across the life time of the LSP using this (path key,
path info) state. 

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

In addition to what is mentioned above:

1. All RSVP TE nodes that perform the ERO computation, already store the
ERO info for the LSP in the Path State block of the LSP. And that too for
the life time of the connection!
2. Use of 5 tuple (RSVP TE FEC) does not suffer from 16 bit path key
scaling issues I outlined in the other email chain.

>
>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
>