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

Zafar,

A given PCE can maintain path state for 64K paths.  Since it is keeping path state it does not need to keep *any* LSP state.  This is simply RFC5553 behavior.   

Yours Irrespectively,

John

> -----Original Message-----
> From: Zafar Ali (zali) [mailto:zali@cisco.com]
> Sent: Monday, November 18, 2013 10:59 AM
> To: John E Drake; Zhangxian (Xian)
> Cc: ccamp@ietf.org
> Subject: Re: 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
> >
> 
> 