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

["LE ROUX Jean-Louis FTRD/DAC/LAN" <jeanlouis.leroux@rd.francetelecom.com>]

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. 

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. 


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 ?


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.

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 ?

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

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.

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.


Hope this will help

Regards

JL