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