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

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

Hi Xian:

Please see in-line.

Thanks

Regards … Zafar


-----Original Message-----
From: "Zhangxian   (Xian)" <[e-mail]>
Date: Thursday, November 14, 2013 10:43 PM
To: zali <[e-mail]>, Fatai Zhang <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: RE: The description of Path Key retaining time in RFC5553

>Hi, Zafar,
>   
>   Thank you for sharing your thought. But I disagree. Why having a
>16-bit PK space will constrain the network to have only 64k LSPs? PK is
>needed only when the LSP is needed to use as a constraint for path
>diversity.

I disagree - 

- How would PCC or PCE know ahead of time which LSP will be used for
diversity by another LSP in a future time? E.g., if you are signaling LSP1
at t1. How would PCC or PCE will know that some other LSP (LSP2) will be
requesting diversity from LSP1 at a future time t2.

> 
>
>   Furthermore, I do not see why storing PKS in PCE for a longer time,
>even if the lifetime of LSP, will cause any scalability issue. PKS can be
>used locally by the PCE (stateless) per node basis

Please stop calling a solution that mandate (path key, path) "states" to
be stored for lifetime of the connection as a stateless solution. It is
stateful w.r.t. Path info states. Let's define a new term for such
stateful PCE and use it. Furthermore, as you solution required PCE to keep
path states for life time of the connection, why not just use stateful
PCE, instead? 


>, i.e. combining PKS + source node address as a way for PCE to solve the
>issue you mentioned below, which is internal to the PCE.
>Do you agree?

No... In your solution a PCE cannot serve more than 64 paths in the
network. If you have a centralized PCE, you cannot have more than 64K LSPs
in the *entire network*. This does not fly.


> If needed, we can capture this in the manageability section.
>
>Regards,
>Xian
>
>-----Original Message-----
>From: Zafar Ali (zali) [mailto:[e-mail]]
>Sent: 2013年11月15日 11:13
>To: Fatai Zhang; Zhangxian (Xian)
>Cc: [e-mail]
>Subject: Re: The description of Path Key retaining time in RFC5553
>
>
>-----Original Message-----
>From: Fatai Zhang <[e-mail]>
>Date: Monday, November 11, 2013 9:09 PM
>To: zali <[e-mail]>, "Zhangxian (Xian)" <[e-mail]>
>Cc: "[e-mail]" <[e-mail]>
>Subject: RE: The description of Path Key retaining time in RFC5553
>
>>Please don't argue scaliblity issue because you can see even a GMPLS node
>>can store lots of informaiton.
>>
>
>Fatai- 
>
>I did not get what you are saying. What I was saying is:
>
>* Tunnel-id is 16 bit. I.e., client name space is 16 bit. There can be
>more than one LSP per tunnel.
>* Path key is 16 bits. I.e., server name space is 16 bits. Each LSP needs
>a Path Key. 
>* There is 1:N relationship between PCC and PCE (server). PCE sever may
>even be centralized.
>* You are requiring (Path key, path info) "state" to be stored at the PCE
>server for the life time of the connections.
>* Path keys have hold-off timer of 30 minutes before they can be reused.
>
>Hence, in your solution, PCE server would run out of Path Keys much before
>clients runs out of tunnel name space. In your solution, if you have a
>centralized PCE, you can only support 64K connection IN THE NETWORK! I am
>not sure why you want to ignore these scaling restrictions.
>
>Thanks
>
>Regards...Zafar 
>
>>
>