Re: Comments on draft-vasseur-ccamp-loose-path-reopt-00.txt

[Jean Philippe Vasseur <jvasseur@cisco.com>]

Hi Jean-Louis,

At 06:06 PM 4/2/2004 +0200, LE ROUX Jean-Louis FTRD/DAC/LAN wrote:
> Hi JP, Yuichi
>
> Please find below comments related to your loose path reoptimization ID
>
>
> 1) General Comment
>
> As regards applicability to inter-area/AS TE, this proposal seems really
> relevant.

Thanks,

> IMHO, mid-point indication of better path/local maintenance may also be
> extended to the case of strictly routed inter-area/AS TE-LSPs whose path
> have been computed thanks to PCE based computation.
> Indeed, if PCE based inter-area/AS path computation allows for timer
> driven reoptimization (the HE LSR periodically sends a PC request to
> check if there is a better e2e path), in return it does not allow for
> event driven reoptimization (PCEs in downstream area/AS won't react to
> any network event, as they are stateless).
> Thus it may, IMHO, be relevant that an ABR/ASBR notify the HE LSR when
> there is a better path or local maintenance in a donwstream area, on a
> strictely routed inter-area/AS TE-LSPs whose path has been computed by
> PCEs, so that the HE LSR trigger a PCE based e2e reoptimization.

This is an excellent point, fully agree.


> 2)
> Section 3:
> IMHO it would be better to encode the ERO Expansion Request in the newly
> defined LSP_ATTRIBUTE Object, or maybe in a
> new dedicated object, as this is not, stictly speaking, an attribute of
> the LSP.
>
> Clarification is required for the Note in 3.1:
> Do you mean that the ERO Exapnsion Request bit itself could directly
> trigger a change of component link in a bundle ?

right


> 3)
> Section 4.1
>
> I would remove the following sentence "In particular, when a better path
>
> is discovered, one could conceivably envisage reoptimizing the TE LSP
> on a mid-point LSR",
> Your draft applies to contiguous LSPs. Mid-point reoptimization cannot
> be envisaged anyway, for the simple reason that this would require
> change in the LSP id that is under strict control of the HE LSR.

I agree, you see what we meant here, but indeed, this could be confusing.

> 4)
> Section 4.3.1
>  "By default,
> an LSR uses the IGP metric in their CSPF to compute the shortest path
> that obeys a set of constraints."
>
> TE metric is the default metric in CSPF isn't it ?

Well sure, this will be fixed. The point was just to mention the 
possibility to use either the IGP or the TE metric to compute the shortest 
path.


> 5)
> Section 4.3.1
>
> The operation that is triggered on a mid-point LSR, on receipt of a Path
> with the ERO expansion desired bit set, is , IMHO not actually an ERO
> expansion but just a new path compuation to the next loose hop.

Right

> Here the
> mid-point LSR does not modify the ERO of the currently signaled LSP.
> Strictly speaking the ERO expansion =  Computation of the path to the
> loose next hop + inclusion of the path in the ERO.
> Actually ERO expansion is triggered on mid-points only when the HE LSR
> starts the make-before-break procedure and signals a new LSP (new LSP
> id).
>
> Thus I would suggest to change the name of the "ERO Expansion Request"
> bit, to "Path Re-evaluation Desired" bit.
>
> Same comment in section 4.3.2: "In this mode, a mid-point LSR whose next
> abstract node is a loose hop
> can locally trigger an ERO expansion (when a configurable timer expires
> or on event-driven basis"
>
> Actually the mid-point LSR does not trigger ERO expansion, but only path
> re-evaluation

This is right (more a question of terminology though).


> 6)
> End of section 4.3.2:
>
> "Note that those modes are not exclusive: both the timer and even-driven
>
> reoptimization triggers can be implemented on the head-end and/or any
> mid-point LSR with potentially different timer values for the timer
> driven reoptimization case".
>
> Agree, but is there really an interest to configure at the same time:
>         -Timer driven reoptimization on head-end LSRs, ie peridoc HE
> reopt request thanks the ERO Expansion bit
>         -Timer driven reoptimization on mid-point LSRs
> This seems quite redundant as the periodic HE reopt request triggers
> periodic path re-evaluation on mid-point LSRs.

Well it is not quite redundant since there might be some cases where it 
might be desirable to configure different timers. For instance, consider 
the fact of a head-end LSR having inter-area/AS TE LSPs traversing 
different area/AS each having different characteristics. You may want to 
have a slow timer on the head-end LSR, and more aggressive timers in *some* 
areas/ASes (ABRs/ASBRs). Note that the receipt of a unsolicited "better 
path exists" notification can have the effect of delaying the next "ERO 
expansion request" sent by the LSR.


> 7)
> I suggest adding the use of the RSVP Notify message as an alternative to
> the RSVP PathErr message, for signaling of better path/local maintenance
> to the Head-End , as this draft actually also applies to GMPLS.

Well I would prefer to keep one message type for the purpose of 
notification rather than 2 (moreover PERR Notify also applies to GMPLS).


> Hope this will help

It does, thanks for your, as usual, very valuable comments.

JP.

> Regards
>
> JL