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

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

Hi John- 

So you agree that a PCE cannot support more than 64K Paths. In a
centralized PCE environment this would mean 64K Path states for the entire
network. If I would assume M =1 (I asked a question for M; you can pick
some other M) this would mean that *network* cannot served more than 64K
LSPs. Recall this scaling restriction is not with RFC5553 (as RFC5553
RECOMMENDS path info to be purged after 10 mins). This restriction comes
from draft-zhang-ccamp-route-exclusion-pathkey-00, which requires path
info to be saved for the life of an LSP (using it).

Given that Path to "LSPs using the Path" is not stored at (stateless) PCE,
how would PCE ever be able to purge the Path state? We keep saying for
life time of the connection but how would PCE know (all) client(s) has
(have) deleted the LSP in question? I.e., how would (and when) PCE be able
to purge the Path states? Again RFC5553 RECOMMENDS a simple (10 min) timer
based mechanism, which does not work for
draft-zhang-ccamp-route-exclusion-pathkey-00.

Thanks

Regards … Zafar


-----Original Message-----
From: "[e-mail]" <[e-mail]>
Date: Monday, November 18, 2013 2:28 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

>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:[e-mail]]
>> Sent: Monday, November 18, 2013 10:59 AM
>> To: John E Drake; Zhangxian (Xian)
>> Cc: [e-mail]
>> 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: "[e-mail]" <[e-mail]>
>> Date: Monday, November 18, 2013 8:56 AM
>> To: "Zhangxian (Xian)" <[e-mail]>, zali <[e-mail]>
>> Cc: "[e-mail]" <[e-mail]>
>> 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: [e-mail] [mailto:[e-mail]] On
>> >>Behalf  Of Zhangxian (Xian)
>> >> Sent: Monday, November 18, 2013 12:22 AM
>> >> To: Zafar Ali (zali)
>> >> Cc: [e-mail]
>> >> 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:[e-mail]]
>> >> Sent: 2013年11月16日 2:56
>> >> To: Zhangxian (Xian); Fatai Zhang
>> >> Cc: [e-mail]
>> >> 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)" <[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
>> >> >
>> >> >>
>> >> >
>> >>
>> >> _______________________________________________
>> >> CCAMP mailing list
>> >> [e-mail]
>> >> https://www.ietf.org/mailman/listinfo/ccamp
>> >
>> 
>> 
>
>