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

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

Comments inline.

Yours Irrespectively,

John

From: Zafar Ali (zali) [mailto:[e-mail]]
Sent: Monday, November 18, 2013 11:08 AM
To: John E Drake; Cyril Margaria
Cc: [e-mail]
Subject: Re: [CCAMP] The description of Path Key retaining time in RFC5553

John-

I understand that but my point was that draft-zhang-ccamp-route-exclusion-pathkey-00 requires path info to be persistent across the life time of the connection.

[JD]  It doesn't say that.  However, given that a PCE maintains path state and not LSP state, it seem perfectly reasonable to assume that a path key is valid for the duration of an LSP's existence, modulo changes in the server network topology that invalidate it.  Also, although it is extremely unlikely that the path state would be deleted, nothing breaks if it is deleted.  The network is simply unable to compute a disjoint route, which can also happen for a variety of other reasons.

Also there is no way to differentiate which LSP will require path info to be persistent vs. requests for which Path info can be purged.

[JD]  Given that a PCE maintains path state and not LSP state, why would it care?

Thanks

Regards ... Zafar

From: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Date: Monday, November 18, 2013 1:24 PM
To: zali <[e-mail]<mailto:[e-mail]>>, Cyril Margaria <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: RE: [CCAMP] The description of Path Key retaining time in RFC5553

Snipped, comment inline

Yours Irrespectively,

John


I do not recall that each LSP needs a path key, each path does, but not each LSP.
So the scalability is not related to amount of LSPs, but the amount of path use, which scale quite differently than the number of LSPs.

I just responded to the same confusion in the other email - sorry for the duplicate.

  *   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.
[JD]   A PCE would return a path key to the initiator of LSP 1.  When LSP2 is signaled, it would include that path key along w/ an indication of whether LSP2 is to be disjointly or congruently routed wrt that path key.  Btw, as has been noted, if one is truly interested in disjoint routing, one should request LSP1 and LSP2 together so that Suurballe can be used.
Perhaps the WG should be developing the signaling to support this.
as stated before, you would support a maximum of 64k Paths, given the diversity constraint you want to support.
In any case the scaling of the solution is to be considered, but is there other problem with that solution?
This solution is attractive as it provides a complete solution ( deploy a PCE colocated with the LSR, only resolving  PKS, the rest is already defined).

If we are using "path-stateful" PCE, why not use "stateful" PCE.

[JD]  Because it is an already defined term w/ a completely different meaning?