Re: [CCAMP] Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Diversity using Exclude Routes

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

> -----Original Message-----
> From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com]
> Sent: Tuesday, October 08, 2013 9:32 AM
> To: Fatai Zhang; John E Drake; CCAMP (ccamp@ietf.org)
> Subject: RE: [CCAMP] Resource ReserVation Protocol-Traffic Engineering
> (RSVP-TE) Path Diversity using Exclude Routes
> 
> Thanks John for pointing that out. When I first read the draft I missed that
> point.
> 
> I see two differences between the two drafts:
> 1. utilization of 5ple vs Path key
> 2. The path diversity draft does not say how to collect the 5ple (which in
> some cases could not be available at all), the path key draft covers this aspect
> also
> 
> Re 1 I have a moderate preference for the path key for the security reasons
> that lead to the definition of the Path Key years ago and secondly it's simpler.
> Re 2 I don't know how the WG will manage the issue of two competing drafts
> (one wg, the other individual) but in any case it's an issue that need to be
> fixed somehow.
> 
> BR
> Daniele
> 
> > -----Original Message-----
> > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On
> Behalf
> > Of Fatai Zhang
> > Sent: martedì 8 ottobre 2013 09:02
> > To: John E Drake; CCAMP (ccamp@ietf.org)
> > Subject: Re: [CCAMP] Resource ReserVation Protocol-Traffic Engineering
> > (RSVP-TE) Path Diversity using Exclude Routes
> >
> > Hi John,
> >
> > Totally agree with you, I already found these two drafts are much
> *useless*.
> >
> > This is why we made a new draft (very simple and useful) and put our
> > feet on the ground.
> >
> > http://www.ietf.org/internet-drafts/draft-zhang-ccamp-route-exclusion-
> > pathkey-00.txt
> >
> >
> >
> >
> > Best Regards
> >
> > Fatai
> >
> >
> > -----Original Message-----
> > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On
> Behalf
> > Of John E Drake
> > Sent: Thursday, October 03, 2013 2:27 AM
> > To: CCAMP (ccamp@ietf.org)
> > Subject: [CCAMP] Resource ReserVation Protocol-Traffic Engineering
> > (RSVP-
> > TE) Path Diversity using Exclude Routes
> >
> > HI,
> >
> > I was reading:   http://datatracker.ietf.org/doc/draft-ietf-ccamp-lsp-
> > diversity/?include_text=1, and I happened to notice the following
> paragraph:
> >
> > "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. "
> >
> > Doesn't this disclaimer effectively render this draft useless?  The
> > draft also does not define how the node that initially signaled the
> > LSP finds the 'node calculating or expanding the route'  nor how it
> > delivers the signaled LSP request to that node.
> >
> > As an aside, the draft:
> > http://datatracker.ietf.org/doc/draft-ali-ccamp-rsvp-
> > te-include-route/?include_text=1 would be subject to the same
> > criticism except that the above quoted paragraph is replaced with:
> >
> > "The above-mentioned use cases require relevant path inclusion
> > requirements to be communicated to the route expanding nodes.  This
> > document addresses  these requirements and defines procedures to
> > address them."
> >
> > Even though this is helpful, the draft doesn't actually define these
> > procedures.
> >
> > Yours Irrespectively,
> >
> > John
> >
> >
> > _______________________________________________
> > CCAMP mailing list
> > CCAMP@ietf.org
> > https://www.ietf.org/mailman/listinfo/ccamp
> > _______________________________________________
> > CCAMP mailing list
> > CCAMP@ietf.org
> > https://www.ietf.org/mailman/listinfo/ccamp
> 