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

John: 

Can you advise what assumptions can be made between Paths served by the
PCE and LSPs using those paths to justify your (hostile) assertion that I
do not understand scalability of
draft-zhang-ccamp-route-exclusion-pathkey-00? E.g., if you assume Path
<--> LSP is 1:M, what is value of M we can assume in debating scaling of
the draft under discussion? Please also see my recent response to Xian.

n.b. BTW I was commenting on scaling issue with
draft-zhang-ccamp-route-exclusion-pathkey-00.txt and not RFC 5553. We are
having technical discussion in a friendly environment. But I am
consistently seeing degrading comments or personal attacks from you :(.

Thanks

Regards … Zafar

-----Original Message-----
From: "jdrake@juniper.net" <jdrake@juniper.net>
Date: Monday, November 18, 2013 8:56 AM
To: "Zhangxian (Xian)" <zhang.xian@huawei.com>, zali <zali@cisco.com>
Cc: "ccamp@ietf.org" <ccamp@ietf.org>
Subject: RE: The description of Path Key retaining time in RFC5553

>Xian,
>
>As Cyril pointed out, Zafar does not understand that RFC 5553 deals with
>paths rather than with LSPs.  Hence his arguments wrt the lack of the
>scalability of an RFC 5553 based solution are specious.
>
>Yours Irrespectively,
>
>John
>
>> -----Original Message-----
>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf
>> Of Zhangxian (Xian)
>> Sent: Monday, November 18, 2013 12:22 AM
>> To: Zafar Ali (zali)
>> Cc: ccamp@ietf.org
>> Subject: Re: [CCAMP] The description of Path Key retaining time in
>>RFC5553
>> 
>> Hi, Zafar,
>> 
>>     Let me summarize a bit, so that whoever follow our discussion are
>>not lost.
>> 
>> 1st viewpoint: you still think that 16-bit PKS is not sufficient, since
>>it limits the
>> number of a LSP within a network to be 64k.
>> Our Reply: the purpose of this draft is to address the LSPs that across
>>UNI
>> and/or multi-domains, *NOT* the LSP within a network. Let's not argue
>> theoretically it can be any number for the former. From current
>>deployment, it
>> is far from enough. Besides, we also provide a PKS+ first node of the
>>encode
>> segment as an alternative for the problem you worry much about, is it
>> enough?
>> 
>> 2nd viewpoint: you believe that the PCE needs to store the PKS
>>information
>> longer than required as RFC5520 and you would like to give a name to it.
>> Our reply: We get your point and will add into our draft this
>>information, as you
>> suggested. However, we disagree to use the term "stateful" since people
>> already accept the definition of stateful PCE in PCE WG. Also, it is
>>meaningless
>> to argue on the terminologies as long as we make the point clear in the
>>draft.
>> Please do not forget that the border node can be the "PCE" for decoding
>>the PK
>> (which you should be much aware of), storing such information is not an
>> problem. Having said that, our draft do not limit the model of how PKS
>>is
>> decoded.
>> 
>>   As usual, we can agree to disagree, but I think we both have made the
>>point
>> clear enough till now.
>> 
>>   Please do not forget the reason we write this draft. As you John
>>already
>> mentioned, we do not see any description in
>>draft-ietf-ccamp-lsp-diversity
>> about how the border node can decode the sub-object defined upon
>>receiving
>> the path diversity constraint, thus there is NO complete solution in
>>your draft. I
>> vaguely remember you mentioned a proprietary method for doing so, do you
>> mean that whoever implement draft-ietf-ccamp-lsp-diversity are forced to
>> need to consult the draft authors for a complete solution? Please
>>consider this
>> in the next update of this draft.
>> 
>> 
>> Cheers,
>> Xian(on behalf of all co-authors of the draft
>>draft-zhang-ccamp-route-exclusion-
>> pathkey)
>> 
>> -----Original Message-----
>> From: Zafar Ali (zali) [mailto:zali@cisco.com]
>> Sent: 2013年11月16日 2:56
>> To: Zhangxian (Xian); Fatai Zhang
>> Cc: ccamp@ietf.org
>> Subject: Re: The description of Path Key retaining time in RFC5553
>> 
>> Hi Xian:
>> 
>> Please see in-line.
>> 
>> Thanks
>> 
>> Regards … Zafar
>> 
>> 
>> -----Original Message-----
>> From: "Zhangxian   (Xian)" <zhang.xian@huawei.com>
>> Date: Thursday, November 14, 2013 10:43 PM
>> To: zali <zali@cisco.com>, Fatai Zhang <zhangfatai@huawei.com>
>> Cc: "ccamp@ietf.org" <ccamp@ietf.org>
>> 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:zali@cisco.com]
>> >Sent: 2013年11月15日 11:13
>> >To: Fatai Zhang; Zhangxian (Xian)
>> >Cc: ccamp@ietf.org
>> >Subject: Re: The description of Path Key retaining time in RFC5553
>> >
>> >
>> >-----Original Message-----
>> >From: Fatai Zhang <zhangfatai@huawei.com>
>> >Date: Monday, November 11, 2013 9:09 PM
>> >To: zali <zali@cisco.com>, "Zhangxian (Xian)" <zhang.xian@huawei.com>
>> >Cc: "ccamp@ietf.org" <ccamp@ietf.org>
>> >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
>> >
>> >>
>> >
>> 
>> _______________________________________________
>> CCAMP mailing list
>> CCAMP@ietf.org
>> https://www.ietf.org/mailman/listinfo/ccamp
>