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

[John E Drake <[e-mail]>]

Zafar,

Lest we forget, I have already pointed out your solution not only requires more state but also requires that this state be kept at orders of magnitude more nodes and that you have not said a word as to how to accomplish this.

Yours Irrespectively,

John

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of Zafar Ali (zali)
> Sent: Friday, November 15, 2013 11:48 AM
> To: Fatai Zhang; George Swallow (swallow); Zhangxian (Xian)
> Cc: [e-mail]
> Subject: Re: [CCAMP] The description of Path Key retaining time in RFC5553
> 
> 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
> >
> 
> _______________________________________________
> CCAMP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ccamp
>