comments on ARO

[stefaan.de_cnodder@alcatel.be]

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