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

[John E Drake <[e-mail]>]

Comments inline

Yours Irrespectively,

John

> <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."


[JD]  Where in RFC 5508 does it say that only one PCED TLV per router can be advertised?  Further, RFC 5508 is but one of many methods of establishing PCEP sessions.


> 
> 
> 
> >
> >> 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.


[JD]   I think you missed the point.  In an optical network there are typically 64 or 128 channels per DWDM line system.  This means that there could be 64 or 128 LSPs routed on the same path through the server and they would all use the same path key. 


> 
> >
> >> 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."


[JD]  Actually, you weren't.  According to you, you were quoting from RFC 5553 and as I pointed out, you were incorrect.

As I indicated above, I think the more relevant text from RFC 5520, which clearly indicates that aggressive cache management isn't necessary, is the following:

"The operation of the PKS extensions require that path-keys are retained by the issuing PCE to be available for retrieval by an LSR (acting as a PCC) at a later date.  But it is possible that the
retrieval request will never be made, so good housekeeping requires that a timer is run to discard unwanted path-keys."


> 
> >
> >>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?


[JD]  Um, I think I was the one that suggested this, when critiquing your drafts.  That would be fine too, particularly if it was augmented to compute disjoint paths concurrently.  It also has the nice property of rendering all of your drafts DOA.  Do we have consensus on this?
 

> 
> >
> >>
> >> 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.


[JD]  Hardly, rather I have been making two points.  Diversely routed paths are typically established concurrently so they should not be
affected by aggressive cache management and there is nothing, other than some vague assertions by you, that indicates that aggressive
cache management  is required to scale PCE performance. 


> 
> 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.


[JD]   A better way to say this is that neither your draft nor this draft solves this problem.  In both drafts, the explicit routes and LSP IDs are available inside the server network but a mechanism is required to distribute this information to the correct PE nodes and neither draft proposes any such mechanism.  I have pointed out this problem in your drafts out to you on numerous occasions but to no effect.