RE: comments on ARO

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

Hi Stefaan,

Just following up on my earlier reply to your comments.

We had promised to respond to your specific comments 
a bit later, and some respones are in-line.

Again, thanks a lot for feedback, it will be very 
helpful in revising the document.

Regards,
-Vishal

PS: A couple that are not addressed here, we will address 
jointly with others, such as when responding to Arthi's
or JL's comments, and will CC you on them.


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

Your understanding is correct. That is, we do _not assume_ that
the primary and secondary paths (or the two diverse paths, to
be more accurate) follow he same areas/ASs.

Thanks for the observation, we will make this clearer in the
next revision.
> 
> 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?

Yes. Thanks for pointing this out, we will specify it clearly
in the upcoming revision.

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

As explained in my earlier response, 
http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00504.html
a difficulty with just recording
the border nodes is that mere knowledge that the secondary is for
some primary, without a knowing the path of the primary is not
sufficient to ensure _diversity_ of the two paths.

This is one of the main goals of the ARO scheme, thus we need
to have knowledge that a primary _and_ a secondary are to
be routed when jointly computing their path at each border node.
 
> 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.


Addressed in detail in my earlier response
http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00504.html.

Briefly, with diversity as the goal, often it may be that the
paths of both the primary and secondary are to be optimized
or made as short as possible, so we cannot just optimize
the one path while ignoring completely the other.

(Even if not, one can get into real sub-optimal network 
operation with unduly long secondary/diverse paths, if their
lengths are not controlled cleverly from the start.)

But, I agree, we will make this clearer in the revised version,
when we focus on diversity, and clarify that protection is one
application of the scheme.

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

Referring to Fig. 5 of the draft, the ingress ABR in Area 2 
would make that selection depending on what metrics it is
optimizing.

> 7) section 4.3: also describe the L-bit that is in the ERO
> subobjects.

Ok, thanks, we will in the next revision.

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

As mentioned in Sec. 4.3.2.1, the address length allows the IPv4
address to be a prefix of length specified by the "Add_Len" field.
So the address length can be different than 32.

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

Thanks for the catch! We will make these consistent.

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

Thanks for the observation and the pointer. As you would see
from my response to JL, we are thinking more about the virtual
link case, and will be able to post some alternatives once
we have given it a bit more thought.


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

Actually, there are several options in each of these cases, and
I have explained some in my earlier response
http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00504.html.

Further inputs from CCAMPers 
on interworking these will be much appreciated.

We can probably add a discussion of some of these interworking
options in the draft, although it is not a goal of the draft
to document all possible interworking scenarios!

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

As explained above, and in my earlier response, the goal is to
ensure that there is a _diverse_ path, not just a path for the
second LSP.

>13) (!) The method seems not to be applicable for inter-AS
>calculations.

Not sure why you say that (perhaps because of point 12?). We have
designed it to be applicable both for inter-area and inter-AS cases.
While some refinement for the inter-AS case would improve the
scheme, we certainly had that inter-AS case in mind when developing
it.

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


As I pointed out in my email to JP, 
http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00467.html

we view the ARO as complementary to the PCS/PCE approach and
to the XRO. The goal in designing it wasn't really to replace
either of these.

In fact, I explained there that the ARO is a hybrid approach
that can 
can compute end-to-end diverse paths like in the PCE approach, with the 
simplicity of the per-domain approach, and without any changes 
to the signaling protocols (save for an ERO-formatted
ARO obj.).

As said earlier, it seems it would be useful for us to put
in a short section discussing complementarity with other approaches.

You already saw some of this in my earlier response to your email,
where I explained how things could work with crankback, re-opt. etc.