RE: comments on ARO

["Vishal Sharma" <v.sharma@ieee.org>]

Hi Stefaan,

Thanks for your follow-on inputs. Few comments in-line.

We look forward to any additional feedback you have.

Regards,
-Vishal

> -----Original Message-----
> From: stefaan.de_cnodder@alcatel.be
> [mailto:stefaan.de_cnodder@alcatel.be]
> Sent: Monday, April 26, 2004 9:26 AM
> To: v.sharma@ieee.org
> Cc: ccamp@ops.ietf.org; Fabio Ricciato; Ugo Monaco; Alessio D'Achille;
> Marco Listanti
> Subject: Re: comments on ARO
>
>
>
> Hi Vishal,
>
> please find some more comments inline...
>
> Vishal Sharma wrote:
> >
> > Hi Stefaan,
> >
> > Thanks a lot for looking over the draft so carefully, and for your
> > many detailed comments.
> >
> > While we will address the individual comments once we've digested
> > them a bit (and in a separate email to avoid making this one
> > too long :-)), let me try to address a couple of the most important
> > points raised in your note below.
> >
> > 1) Recording only border nodes:
> >
> > Actually, if one only recorded border nodes, then upon signaling
> > the secondary, the ingress border node for the secondary has no
> > idea about the intra-area (or intra-AS)  path of the primary (in its
> > own area or AS), and therefore cannot ensure that the primary and
> > secondary segments are in fact disjoint.
> >
> > This was a point I discussed with several other people
> > (who initially proposed the same thing), including
> > Arthi and Adrian, but we concluded, for the reason above, that merely
> > recording the border nodes does not work for diversity. As a
> > result, the ARO does, in fact, serve a very useful purpose.
> >
> > We can of course think more about what the trade-offs are, and
> see if there
> > is some way to retain the main advantage of the proposal (diversity,
> > joint optimization of both paths) while also recording less information.
> >
>
> The problem I want to solve here is NOT to reduce the amount of
> information in the ARO, i.e. my purpose is not to reduce its length.
> Rather, by only recording the border nodes you give more freedom
> when signaling the secondary (using the XRO!) meaning that when
> crankback or re-optimization of the secondary is possible, the
> primary does not have to be resignaled to get a new ARO.

Sure, I understood that the goal wasn't to reduce the length of
the ARO per se, but rather the level of detail that would need to
be recorded in it (regardless of the actual amount of data the ARO
would carry).

If you recollect the classification of path computation models
I gave in my email to JP
http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00467.html

we have under distributed computing: i) a parallel path computation
model and  ii) a sequential one.
ARO achieves the former, while XRO achieves the latter.

So, if one did not compute and record the path of the secondary
jointly with the primary (and only recorded the border nodes instead)
the scheme would reduce to a _sequential path computation_, with its
attendant drawbacks (sub-optimality, trap topology, etc.).

The beauty of the ARO scheme is that it can compute end-to-end
diverse paths using a parallel path computation model (albeit distributed
at each area/AS), with the simplicity of the  per-domain approach, and
without any changes to the signaling protocols.

Please note also that this does not say anything about the usefulness of
the XRO (which _is_ a v. useful construct, with several applications, as
pointed out in my earlier email), only that when paths are computed
sequentially these problems arise.

>
> > 2) With regard to optimizing only the path of the primary, I am not
> > so sure about doing just that.
> >
> > I believe one can get into real problems if one does not constrain
> > the path/cost of the secondary, with unduly long secondaries that
> > will greatly limit the ability to setup further primaries
> > (and secondaries). (This can be especially true of tranport networks,
> > where one would set up very large bandwidth pipes, and optimizing their

> > placement would be critical.)
> >
> > This scheme is optimizing jointly the cost of the primary and
> > secondary, while ensuring diversity.
> >
>
> My question was *what* is the metric being optimized. For instance
> with sequential computing, the cost of the primary is minimized,
> while the second metric is the cost of the secondary LSP. With
> parallel computing it is different: is the cost being minimized the
> cost of primary + cost of secondary, or is it something else?

Minimizing the cost of the primary + cost of secondary is one metric
that a parallel path computation scheme may minimize. There might
be others. For e.g. minimize the cost of primary while keeping that
of secondary below a certain threshold, minimize the difference
between the costs of the primary and the secondary, and so on.

The actual criteria for minimization may be a provider choice,
that is executed/realized by the joint path computation algo.
employed in the network nodes.

> > I think you will find that most providers would be equally concerned
> > with the cost/placement of the secondary path.
> >
> > Moreover, as I emphasized (and as discussed during CCAMP we wiil change
> > the title and our intro. to reflect that), this is a:
> > generic method for computing diverse paths
> > that meets a variety of requirements: load balancing, multipe paths
> > when a single one has insufficient capacity, multiple paths between
> > VoIP gateways, etc. in all of which one would ideally be looking for
> > paths with about equal length.
> > Protection is just _one_ application of this scheme.
> >
>
> This load balancing over multiple paths looks like a good
> application.

Great, thanks. This is why JL and others have asked us to
not limit our scheme only to restoration applications.

And we will do this generalization in the update.

> > 3) Re-optimization, crankback, and failure of secondary:
> >
> > I think the scheme works with all of these, and does not really
> > conflict with any of them.
> >
> > With crankback, there should be no problem, whenever a crankback occurs
> > on the primary, the secondary will also be recomputed at the ASBR/ABR
> > to which there is crankback.
> >
> > With re-optimization, there are several options.
> >
> > -- Either default to sequential calculation, and use the XRO to
> re-optimize
> > whichever of the two diverse paths requires re-optimization.
> > (This might be an immediate response, while the below could be
> > a more long-term response.)
> >
>
> Since an ABR on the secondary path only sees a full strict path in
> the ERO, the ABR does not know when there is a better path matching
> the constraints. This is because the ABR does not know the
> constraints.
>
> > -- Or, if the goal really is joint optimization, the provider will have
> > to setup a new set of diverse paths, and use make-before-break to
> > transition the traffic over.
> >
> > -- If the secondary fails, again there are two options. Either use
> > the XRO to perform another path setup (and, possibly, re-optimize
> > the paths later), or use the joint optimization method above with
> > make-before-break.
> >
>
> This looks ok.

Great, thanks. We will add this discussion to our revised
draft.

>
> > 4) Relationship to XRO:
> > As I mentioned in the Seoul presentation and also
> > in our discussion, I think the XRO has many uses -- during computation
> > after crankback, to enable adminstrative routing/re-routing, protection,
> > etc.
> >
> > So I think the ARO and XRO are actually complementary.
> >
> > Regards,
> > -Vishal
> >
> > > -----Original Message-----
> > > From: stefaan.de_cnodder@alcatel.be
> > > [mailto:stefaan.de_cnodder@alcatel.be]
> > > Sent: Monday, April 19, 2004 12:08 PM
> > > To: v.sharma@ieee.org
> > > Cc: ccamp@ops.ietf.org
> > > Subject: comments on ARO
> > >
> > >
> > >
> > > Hi Vishal,
> > >
> > > looking to draft-dachille, I have following comments:
> > >
> > > 1) Second paragraph in section 2 is not clear: "we will assume that
> > > every
> > > inter-area connection is duplicated". I understood from it that when
> > > the
> > > primary path follows Area1-Area2-Area3, then also the secondary has
> > > to
> > > follow this path but using other border nodes. But then from section
> > > 4.2 I
> > > understand that this is not an assumption?
> > >
> > > 2) step 2c on page 5: also E, G and H has to be pruned? It is also
> > > not
> > > clear which path is selected in area 3: I guess it is E-G-H for
> > > primary and
> > > F-H for secondary?
> > >
> > > 3) (!) page 7, about the trap-avoid reference: If fact it is just a
> > > matter
> > > of doing a good path calculation. If the primary is signaled and
> > > border
> > > nodes know that also a secondary has to be established, then it can
> > > make
> > > sure that the primary does not introduce such a trap. This assumes
> > > that the
> > > border node also has to know that a secondary has to be established.
> > > This
> > > is known by the presence of the ARO object but this does not mean
> > > that at
> > > the end, the ARO has to contain a full strict path of the secondary.
> > > Border
> > > nodes can expand the ARO by only including the border nodes for the
> > > secondary. This means that the path calculation of the secondary is
> > > not
> > > anymore 100% bound to the primary. Also I would prefer that the ARO
> > > is more
> > > like a "hint" than the real path. With this, you do not have to
> > > interaction
> > > problems with re-optimization of secondary, crankback, ... For
> > > instance:
> > > when the secondary fails, it can be re-established ignoring the ARO.
> > > Or
> > > when the secondary can be re-optimzed between border nodes, then it
> > > can be
> > > done without impacting the primary or when the global
> > > re-optimization is
> > > possible, then the ARO can be simple ignored.
> > >
> > > I prefer to have the ARO only recording border nodes, and optionally
> > > only
> > > acting as a hint for the ingress LSR. The latter is less important
> > > to me.
> > >
> > > 4) text below figure 3: primary has to be as short as possible. I do
> > > not
> > > care much about the secondary becuase it is almost never used. Also,
> > > the
> > > resources that it reserves can be shared with other secondaries. The
> > > problem here is: what are you optimizing? According to me the path
> > > of the
> > > primary has to be optimized.
> > >
> > > 5) I do not understand why the ARO has to contain Area-Ids to
> > > indicate the
> > > route. If the ingress can put the "area-path" in the ARO, then it
> > > can also
> > > put the border nodes in the ERO of the secondary immediately. I.e.
> > > refering
> > > to figure 5: A knows that the path of the secondary is A1-A2-A5-A6.
> > > How
> > > does A know this? And if it is possible to let A know this
> > > information,
> > > then why could it also not know that the path is B1-B7-B9. If A can
> > > do
> > > this, then there is no need anymore for ARO. So the basic question
> > > is: what
> > > makes it easier for A to know A1-A2-A5-A6 instead of B1-B7-B9. This
> > > means
> > > to me that section 4.2 is not valid and that the ARO assumes that
> > > the
> > > "area-path" of primary and secondary is the same, which is true for
> > > IGP
> > > areas. See also comment 2. Maybe better to remove the AREA-IDs from
> > > the
> > > ARO.
> > >
> > > 6) step 1d page 14, second last line: how does the ABR know that B7
> > > has to
> > > be used and not B8?
> > >
> > > 7) section 4.3: also describe the L-bit that is in the ERO
> > > subobjects.
> > >
> > > 8) Is the Addr_len in for instance subobject 1 always 32 or can it
> > > be
> > > something else. I agree here that you should re-use ERO subobjects
> > > but I
> > > see that you are doing this.
> > >
> > > 9) Section 4.3.2.3, area_ID: types 3, 4 and 5 are defined but that
> > > conflicts with what is described in the middle of page 19 where the
> > > numbers
> > > are 32, 33, 34.
> > >
> > > 10) the text in section 4.3.3 is rather confusing (the part in the
> > > middle
> > > of page 22, about pruning the nodes). Take figure 5, area 5: If B6
> > > has to
> > > calculate a path from B6 to B10, then this path can pass via B5, B8,
> > > B7
> > > and/or B9. This is because border nodes can also act as core nodes
> > > at the
> > > same time. This seems to be excluded from the draft. Is that
> > > correct?
> > >
> > > 11) First refinement in section 5 about the cost of virtual links:
> > > this has
> > > been proposed before in
> > > http://www.watersprings.org/pub/id/draft-venkatachalam-interarea-m
> > >pls-te-02.txt
> > >which is not a good idea: it only works for inter-IGP area and it
> > >decreases
> > >the scalability although it also has some advantages.
> >
> > >12) (!) There are conflicts with re-optimization, crankback,
> > >re-establishement after failure of secondary LSP, ... because in all
> > >of
> > >these cases a working primary LSP also have to be re-signaled which
> > >is not
> > >good. Therefore it is better to let the ARO only record border
> > >nodes,
> > >and/or to use the ARO more as a hint for the secondary: using the
> > >ARO in
> > >the primary makes sure that a trap is avoided, and then it is up to
> > >the
> > >signaling of the secondary to find this path by using crankback,
> > >.... There
> > >is no need that the primary LSP also gives the path, it only has to
> > >make
> > >sure that there is a path.
> > >
> > >13) (!) The method seems not to be applicable for inter-AS
> > >calculations.
> > >
> > >14) Following the classification of methods (ARO, XRO, PCE) that you
> > >described earlier on ccamp based on parallel/sequential and
> > >distributed/centralized computation, ARO looks more an alternative
> > >for PCE than for XRO? In fact, would it be possible to combine
> > >methods? It would be good to explain the interaction (if any) with
> > >these other methods.
> > >
> > >Hope this helps,
> > >
> > >regards,
> > >
> > >Stefaan