RE: comments on ARO

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

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.

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.

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.

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.)

-- 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.

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