Re: [CCAMP] WG Last Call on draft-ietf-ccamp-lsp-diversity-03

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

Zafar,

We still need a general solution which both draft-fedyk-ccamp-uni-extensions<http://tools.ietf.org/id/draft-fedyk-ccamp-uni-extensions-03.txt> and draft-zhang-ccamp-route-exclusion-pathkey<http://tools.ietf.org/id/draft-zhang-ccamp-route-exclusion-pathkey-00.txt> appear to provide and they both could also be used in the situation for which you are now claiming your draft was designed.  So, I don't see any reason to progress your draft.

Furthermore, your draft has a fundamental design flaw which is that it uses established LSP state to indirectly reference established path state.  Since there are orders of magnitude more established LSPs than established paths, you have to maintain orders of magnitude more state, and this state needs to be distributed to any node that might be called upon to compute a route or expand a loose route.

Yours Irrespectively,

John

From: Zafar Ali (zali) [mailto:[e-mail]]
Sent: Saturday, February 08, 2014 1:07 PM
To: John E Drake; BRUNGARD, DEBORAH A; [e-mail]
Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-lsp-diversity-03

Hi John:

In most of the cases, when the UNI-N node computing the path is also hosting the RSVP-TE FEC against which exclusion is required, it knows the  path take by the other LSP. For the other cases, please note that just  because optical network is running GMPLS UNI for client interface does not  mean that it is running RSVP-TE for the optical trail management. E.g., optical  trail management can still using an already deployed proprietary mechanisms  or an NMS based scheme. The draft is addressing schemes that are capable of this functionality. We can add specific clarification text.

Thanks

Regards ... Zafar

From: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Date: Thursday, February 6, 2014 3:46 PM
To: "BRUNGARD, DEBORAH A" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-lsp-diversity-03

Deborah,

I don't want to see this draft progressed.  Technically, I think the path key approach (http://tools.ietf.org/html/draft-zhang-ccamp-route-exclusion-pathkey-00) is far superior and as I noted in an email sent on 10/8/13 and copied below for your convenience, this draft has significant technical issues in that it does not specify how a GMPLS network would perform the functions specified in the draft.

Ironically, the authors of the draft explicitly acknowledge this:


"The means by which the node calculating or expanding the route of the signaled LSP discovers the route of the path(s) from which the signaled LSP requires diversity are beyond the scope of this document."

Yours Irrespectively,

John

=======================================================================================================================================================

Daniele and Fatai,

I have been thinking some more about Zafar's Exclude/Include drafts and I have the following observations.

Let's assume that the ingress node has the RSVP-TE explicit route and identifier for a given LSP from which it wishes to have a subsequent LSP be disjointly routed (exclude route) or be identically routed (include route).

For either full or partial exclude route, where partial exclude route means a disjoint route across one or more abstract nodes, the ingress node can compute a route that is disjoint from the route of the given LSP.  (However, it is not guaranteed that a disjoint route can be found.  The Suurballe algorithm computes disjoint routes *in pairs* and will find disjoint routes if they exist.) In order to allow the ingress node at the edge of an abstract node to expand the explicit route and provide a disjoint route will require that each such ingress node has complete knowledge of the RSVP-TE explicit route and identifier of every LSP transiting that abstract node.

For full include route the ingress node can simply re-use the explicit route from the selected LSP.   For partial include path, where partial include path means an identical route across one or more abstract nodes, it can simply re-use the [ingress node, abstract node] tuple for the subject abstract node.

Let's now assume that the ingress node has the RSVP-TE identifier for the given LSP but not the explicit route.  This is the UNI case, and if the ingress node is single homed then the ingress PE can act on the ingress node's behalf as described above.

If however, the ingress node is multi-homed then this will require that each of the ingress PEs know the complete set of ingress PEs serving the ingress node and each has the RSVP-TE explicit route and identifier for the given LSP.  This allows each ingress PE to act on the ingress node's behalf as described above.

The net of all this that there needs to be a lot of distributed and coordinated state maintained in the server network and that neither Zafar nor any of his co-authors has proposed a method for accomplishing this.

Yours Irrespectively,

John

From: CCAMP [mailto:[e-mail]] On Behalf Of BRUNGARD, DEBORAH A
Sent: Thursday, February 06, 2014 12:06 PM
To: [e-mail]<mailto:[e-mail]>
Subject: [CCAMP] WG Last Call on draft-ietf-ccamp-lsp-diversity-03

All,

This starts a two-week working group last call on draft-ietf-ccamp-lsp-diversity-03.

This working group last call ends Feb. 20th. Please send your comments to the CCAMP mailing list.

Deborah and Lou