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

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

Hi John- 

Please see in-line.

Thanks

Regards Š Zafar


<snip> 
>> 
>> Hi John-
>> 
>> So you agree that a PCE cannot support more than 64K Paths.
>
>[JD]  There are 64k path keys associated with a given PCE address.  There
>is no requirement that a PCE
>have only one address.

This is incorrect. One address per PCE is a requirement as per rfc5088.
Quoting from http://tools.ietf.org/html/rfc5088#page-7

"The PCE-ADDRESS sub-TLV is mandatory; it MUST be present within the
   PCED TLV.  It MAY appear twice, when the PCE has both an IPv4 and
   IPv6 address.  It MUST NOT appear more than once for the same address
   type.  If it appears more than once for the same address type, only
   the first occurrence is processed and any others MUST be ignored."



>
>> 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.
>
>[JD]  in an optical network a more realistic number is in the range
>64-128, resulting in 4,096,000 - 8,192,000
>LSPs, again per PCE address.

I am not sure where you brought 64-128 bit space. In rfc5520, PCE Path Key
is defined as a 16 bit number.

>
>> Recall this
>> scaling restriction is not with RFC5553 (as RFC5553 RECOMMENDS path info
>> to be purged after 10 mins).
>
> [JD]  That's incorrect.  RFC 5553 does not say a word about this.  RFC
>5520 recommends that a path key be *kept*
> for at least ten minutes and indicates that this value is configurable.
>It also indicates that the purging of path state
>is simply a house keeping procedure.

I was quoting following text from rfc5520:

"It is RECOMMENDED for a PCE to store the PKS for a period of 10 minutes."

>
>>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).
>
>[JD]  That's incorrect.  It *does not* say this.  Further, why would
>diversely routed LSPs not be established concurrently?  If they are not,
>it defeats the purpose of having diversely routed LSPs.

In that case, why cannot we use RFC5440 (SVEC object), instead? Why do you
need draft-zhang-ccamp-route-exclusion-pathkey-00?

>
>> 
>> 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?
>
>[JD]   It continues to purge path state as per RFC 5520.  Nothing breaks
>if the path state is purged, and path state can also be
>invalidated due to depletion of server network resources or changes in
>server network topology.
>  

So you agree that the solution is broken. It only works sometimes.

Speaking of handling changes in server topology. This is another aspect
that draft-zhang-ccamp-route-exclusion-pathkey-00 does NOT talks about at
all. In this respect, please note that:

1. A PCC that does not have server topology (UNI, which is target case for
this draft). So it cannot verify Paths or check if diversity is still met.
2. A passive PCE can verify Paths and can detect if diversity is still met
but cannot take action.

So once draft-zhang-ccamp-route-exclusion-pathkey-00 sets up the service,
it cannot handle topology changes.

> 
>
>[> 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.
>
>[JD]  See my previous comments.
>
>