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

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

John-

In-line please.

Thanks

Regards … Zafar

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

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]<mailto:[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?

If LSP1 is signaled at t1 (using PK1). How would PCC or PCE will know that some other LSP (LSP2) will no longer be requesting diversity from LSP1 (using PK1) at a future time t2? I.e., when PCE can purge PK1? If PK1 is purged before t2, the solution did not address the requirement. On the other hand, PCE needs to purge Path states to scale.

Please also see my response to the other email w.r.t. Difficulties in purging Path Keys in the way draft-zhang-ccamp-route-exclusion-pathkey-00 is using it.


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?