Subject: Working Group Last Call draft-ietf-ccamp-loose-path-reopt-

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 5 Jan 2005 18:40:30 -0000

This email starts a two week last call on
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-loose-path-reopt-00.txt

Please send your comments to the list or to the chairs by noon GMT on 20th
January 2005.

Thanks,
Adrian and Kireeti

---

From: dimitri papadimitriou <[email-masked]>
Date: Thu, 06 Jan 2005 12:15:30 +0100

adrian, all,

some comments:

1. section 2: "The path computation may either be performed by
    means of CSPF or any Path Computation Element (PCE) and can be
    partial (up to the next loose hop) or complete (up to the TE LSP
    destination)."

two point here, the "or" in the first part of the sentence does not 
compare comparable things (an alogrithm versus a computation entity)
i think what you mean is "locally" or via an external computation 
element - i think the end paragraph of section 5.3.1 confirms my 
comment-  the second relates to the second is the word "complete" 
meaning strict under the tunnel end-point address ?

2. in the note, another terminology is introduced "full" i guess it has 
the same meaning as complete ?

3. i do not see the relationship of including the following paragraph 
(in the following paragraph " There is another scenario whereby 
notifying the head-end of the existence of a better path is desirable: 
if the current path is about the fail due to some (link or node) 
required maintenance (see also [GR-SHUT]).") within the context of this 
document as non-time sensitive mechanism is targeted here while the 
referenced document targets time-sensititve mechanism (existing LSPs are 
about to fail and not existing LSP can be re-optimized due to the 
existence of additional resource) however this point triggers to me the 
following question in case of link/node down for maintenance reasons 
what gives the guarantee that the head-end will respond on time before 
the maintenance operation is performed

4. section 4.: "New ERO flags and Error value sub-codes are proposed in 
this document (to be assigned by IANA)." i don't see any new ERO flag 
defined as far as my reading goes

5. section 5.3.1 to which LSR (intermediate vs head-end) the first LSR 
mentioned refers to "At this point, the LSR MAY decide to clear the 
ôPath re-evaluation requestö bit of the SESSION-ATTRIBUTE object in 
subsequent RSVP Path messages sent downstream:" and what "subsequent" 
refers to in the present context

6. section 5.3.1 "Note that the head-end LSR might use the METRIC-
    TYPE object (defined in [PATH-COMP]) in its path message to request
    the LSR having a next hop defined as a loose hop or an abstract node
    in the ERO to use another metric to determine a preferable path." do 
not appropriate to introduce alternatives based on objects and methods 
at this point in time in the document additionally these methods have 
never been discussed before therefore a more generic statement should 
replace the above statement allowing for future improvments when validated

7. section 5.3.2. " In this case, the mid-point LSR where the
    local maintenance must be performed is responsible for sending an
    RSVP PathError message with Error code 25 and Error sub-code=7 or 8
    depending on the affected network element (link or node)." my 
reading of all previous content was that in such a case the mid-point 
LSR is not the local maintenance point is realized - inline with what 
follows down this paragraph -

some edits

1. the document should refer to "PathErr" message and not "Path Error", 
   or "PathError"

2. section 3. reference to make-before-break i.e. RFC 3209 should be 
provided

3. there are lot of spurious charcaters such as ô, ö, etc.

thanks,
- dimitri

Adrian Farrel wrote:

> .

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 14 Jan 2005 11:43:28 -0000

Here are my comments on this draft.

It is a great shame to see an I-D put up for last call when it fails the idnits script. In particular, since this concerns how the IPR statements are interpreted, it is crucial that these issues are resolved before the draft can move forward. Additionally it is a matter of courtesy to the readers to resolve the formatting issues.

It seems to me that this draft is applicable to a strict ERO where one of the hops is a non-specific abstract node such as an AS number. This is made clear in section 2, but the Abstract and Introduction (yeah, and also the title and draft name) do not adequately expose this fact. But, further, the Introduction talks only about reoptimization without any mention of loose hops or abstract nodes. Thus the draft is schizoid to the third degree - is this loose path reoptimization, reoptimization of loose and non-specific abstract nodes, or general reoptimization? The draft needs to be consistent and clear.

The title contains acronyms which need to be spelled out (MPLS and LSP).

The Abstract is too long. Need it about half the length. You can move some of the material into the introduction which is currently rather short (shorter than the abstract!) Same comment about acronyms (MPLS, GMPLS, TE, LSP, ERO) - make sure they are expanded for their first usage.

Conventions used in this document. Contains unresolved citation.

Section 2
s/Ipv4/IPv4/

Section 2 states that an ERO expansion is either up to the next loose hop or to the destination. But, in fact, the ERO expansion may also be any partial fragment towards either of these targets (including next hop resolution). I suggest re-wording this paragraph to list (as bullets) what an ERO might contain, and in a separate list, what the computation might produce.

Section 2
s/The path an/The path of an/

Section 2.
s/head-End/head-end/

In section 2 I don't like the distinction between "CSPF or any other PCE-based path computation method". Part of the implication here is that PCE might not perform CSPF! I suspect you are trying to highlight that the computation may be performed locally of remotely. I don't think this is relevant to this I-D; you should simply say "invokes path computation".

Section 2
[RSVP-TE] unresolved normative reference.

Section 4.1
s/but instead just signal/but instead just signals/

In section 4.1 you add a note about the selection of component links from within a bundle. While this is true, it is unclear why you pick this case out but don't describe the selection of alternate resources (e.g. lambdas). This is associated to the new error values defined in section 4.2. How would you report a component link going oos? How would you report a link resource (e.g. a lambda) going oos? If you use "local link maintenance required" won't the computing node believe that the whole link is unusable? If your answer here is that the recomputation will ignore the error value and will perform a recomputation based on the new TED (see [GR-SHUT]) then why do you need to distinguish between link maintenance required and node maintenance required? If you actually need to report the component link or resource as a separate quantity, I suggest you refer to the crankback draft.

Section 4.1
I'm not comfortable with the Session Attributes toggling like this. This type of function is what the Admin Status object was invented for.

Section 5.3.1
   This 
   bit is then cleared in subsequent RSVP path messages sent downstream.
This implies that a Path refresh *never* carries this bit set (which makes it a trigger when it comes after a Path with the bit set).
Thus we may lose the request (either through a lost Path message, or through a refresh catching up with a trigger Path message). I think we discussed this before. You need to make it clear in the draft that these requests can be lost.
I think it is also worth considering how to prevent the toggling off of the bit from appearing as a trigger message.

Section 5.3.1
        At this point, the LSR 
        MAY decide to clear the ?h re-evaluation request?t of the 
        SESSION-ATTRIBUTE object in subsequent RSVP Path messages sent 
        downstream: this mode is the RECOMMENDED mode for the reasons 
        described below.  
It really isn't a matter of clearing the bit, so much as not propagating it. That is, it is not necessary to send a new Path message at this point.

Section 5.3.1
[PATH-COMP] is required as a normative reference.

In section 5.3.2
        - The link (sub-code=7) or the node (sub-code=8) MUST be 
        locally registered for further reference (the TE database must 
        be updated) 
What does "the TE database must be updated" mean? Are you saying that the TED is now built from information flooded by the IGP *and* by information fed back from signaling? If so (and I don't approve!) then you must define what happens when you receive a new LSA for the specific link that contradicts the information signaled. There is a strong argument that says that *the* method we use for building the TED is IGP flooding - if this mechanism doesn't provide you with the information you need, then you should propose extensions to the IGP, not hook the information onto signaling.
OTOH it may be that all you mean is that the Session state should be updated to indicate the link or node that is being shut down so that later recomputation can avoid this link. In this case, I suggest you refer to the CCAMP crankback draft.

In section 5.3.2
        - ... Note that in the case of TE LSP 
        spanning multiple administrative domains, it may be desirable 
        for the boundary LSR to modify the RSVP PathError message and 
        insert its own address for confidentiality reason. 
Yes. Good point, but doesn't the error code also need to change? Otherwise it will appear that the border node is the node being taken oos.

Section 5.3.3. suggests the use of a timer. You must, therefore, suggest a default time value. I suspect that you want to suggest some basic multiple of the path computation time or of the IGP refresh period.

Section 6
Need to describe the processing by an LSR that does not understand the new flag (rather than understand it but not support it). note that you cannot define the behavior of legacy LSRs in this draft, so you must reference behavior defined in some other document.
Ditto the new error code.

Section 7
This technique has implications for the trust model between domains. In particular, one domain may cause another to perform additional (excess or unnecessary) work simply to ease its own task or for malicious reasons. Similarly, a headend domain might choose to ignore the requests for re-optimization issued by another domain. I think you need to point out that the peering agreements between domains need to include a definition of how this technique is supported.

Section 10
"Normative references" and "Informative references" need section numbers

Full Copyright Statement
Unnecessary quote marks.

Question...

How does the process of unsolicited notification (of a potential better path rather than of a link going oos) avoid thrashing races? As a very simple example, consider the following n/w.

<-A1-> <--A0-> <-A2->
A-----B       C-----D
      |       |
      |       |
E-----F---G---H-----I

Set up two LSPs AI and ED using EROs {A,B(L),H(L),I} and {E,F(L),C(L),D} producing paths ABFGHI and EFGHCD.

Now install a *low* bandwidth link BC capable of carrying either but not both LSPs. Both B and F will notice that the LSPs entering A0 through them can be re-optimized and will report the fact to A and E respectively. Both A and E will attempt mb4b, but (of course) only one will succeed. In a small network, this is not a big deal, but in a large network with a lot of LSPs this is clearly a waste of processing and will cause a degree of network thrash maybe only in the control plane, but maybe in the data plane if a lower priority LSP is re-routed first. In fact, this scenario can cause significant disruption in the data plane as the re-routed LSP will be preempted and could have been successfully left in its original place.

It seems that a considerably sophisticated policy is required for any domain, but particularly core domains like A0. In effect, the domain needs to evaluate the new link by examining all LSPs in the system and selecting which one(s) should be re-optimized. This type of processing is non-trivial and uses information stores that are not generally available (i.e. LSP maps). 

Thus I would suggest removing the unsolicited notification of reoptimization opportunities (while retaining the unsolicited notification of links going oos) or requiring that the policy be timer-based not event triggered.

Adrian

---

From: Arthi Ayyangar <[email-masked]>
Date: Thu, 20 Jan 2005 11:51:23 -0800 (PST)

Adrian, all,

Just a few comments on this draft.

Section 2 and elsewhere: there are repeated statements & notes as to "CSPF
or any other PCE-based path computation method"
--> I don't think it is relevant to this document whether the path
computation is local or remote or done by a PCE or not. IMO, it would be
enough to just say "path computation".

Paragraph 4 in Section 3, Section 4.2, and 2nd and 3rd paragraphs in 5.3.2
----> This draft not only refers to another draft (and it is *not* a
normative reference) draft-ali-ccamp-mpls-graceful-shutdown-00.txt, but
also seems to introduce error codes and subcodes (subcode 7 & 8) which are
actually relevant to GR-SHUTDOWN draft rather than this document. IMO, if
graceful-shutdown procedures need new error codes/subcodes, they must be
introduced in the graceful-shutdown draft and not in this re-optimization
draft. Otherwise, what is the point of having the other draft if the
codes are being standardized here ?

thanks,
-arthi

So the

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 21 Jan 2005 11:37:43 -0000

OK,

This concludes the WG last call on this draft.

Authors/editors: you got comments from four people, some of them fairly
detailed. I think there is probably a fair bit of work to do.

As guardians of this draft on behalf of the working group, I'd like to ask
that you track all of the comments and record either the agreed discussion
that means that no action is required, or the agreed resolution and change
to the draft.

Thanks,
Adrian

---

From: JP Vasseur <[email-masked]>
Date: Fri, 21 Jan 2005 18:06:29 -0500

Hi Adrian,

> that means that no action is required, or the agreed resolution and  

Sure, will be done shortly.

Cheers

JP.

---

From: JP Vasseur <[email-masked]>
Date: Mon, 24 Jan 2005 04:22:45 -0500

Hi Dimitri,

Thanks for your comments - see in line, (removed comments are the ones  
that we agree on and which will be incorporated in the next revision).

On Jan 6, 2005, at 6:15 AM, dimitri papadimitriou wrote:

> required maintenance (see also [GR-SHUT]).") within the context of  
> this document as non-time sensitive mechanism is targeted here while  
> the referenced document targets time-sensititve mechanism (existing  
> LSPs are about to fail and not existing LSP can be re-optimized due to  
> the existence of additional resource) however this point triggers to  
> me the following question in case of link/node down for maintenance  
> reasons what gives the guarantee that the head-end will respond on  
> time before the maintenance operation is performed
>

the point here is simply that a better path is not restricted to the  
situation where a lower cost path is found but also when the path is  
about to be invalidated due to maintenance. No assumption is made on  
action triggered on the Head-end LSR. (that said, reference has been  
removed).
> refers to in the present context

"The LSR" refers to the LSR performing the path re-evaluation and  
"subsequent" refers to the Path messages used to refresh the states  
downstream for the TE LSP. Text added. 	

> follows down this paragraph -

You're right, the text was ambiguous ... and has been changed for  
"There are other circumstances whereby any mid-point LSR MAY send an  
RSVP PathError message with the objective for the TE LSP to be rerouted  
by its head-end LSR: when a link or a node will go down for local  
maintenance reasons. In this case, the LSR where a local maintenance  
must be performed is responsible for sending an RSVP PathError message  
with Error code 25 and Error sub-code=7 or 8 depending on the affected  
network element (link or node). "

> some edits

Fixed.

Thanks for your comments.

JP.

---

From: JP Vasseur <[email-masked]>
Date: Mon, 24 Jan 2005 04:39:08 -0500

Hi Arthi,

> enough to just say "path computation".

This was for the sake of illustration but I agree of course. Text  
updated, thanks.

> codes are being standardized here ?

Agree, ref to GR-SHUTDOWN has been removed and draft GR-SHUTDOWN will  
be updated accordingly.

JP.

---

From: JP Vasseur <[email-masked]>
Date: Tue, 25 Jan 2005 14:34:06 -0500

Hi Adrian,

> that means that no action is required, or the agreed resolution and  

sure, new rev incorporating comments will be posted soon.

Thanks.

JP.

---

From: JP Vasseur <[email-masked]>
Date: Tue, 25 Jan 2005 14:33:45 -0500

Hi Adrian,

Agreed comments have been removed - See in line,

On Jan 14, 2005, at 6:43 AM, Adrian Farrel wrote:

> It seems to me that this draft is applicable to a strict ERO where one 
> of the hops is a non-specific abstract node such as an AS number. This 
> is made clear in section 2, but the Abstract and Introduction (yeah, 
> and also the title and draft name) do not adequately expose this fact. 
> But, further, the Introduction talks only about reoptimization without 
> any mention of loose hops or abstract nodes. Thus the draft is 
> schizoid to the third degree - is this loose path reoptimization, 
> reoptimization of loose and non-specific abstract nodes, or general 
> reoptimization? The draft needs to be consistent and clear.
>
>
>

Agree, the following definition has been adopted throughout the 
document: "A loosely routed LSP is defined as an LSP that follows a 
path that contains at least one loose hop or a strict (abstract node) 
hop"

I guess that the document title can remain unchanged considering that a 
loose path also includes the case of a path where at least one hop is 
an abstract node.

> The title contains acronyms which need to be spelled out (MPLS and 

Added

> The Abstract is too long. Need it about half the length. You can move 
> some of the material into the introduction which is currently rather 
> short (shorter than the abstract!) Same comment about acronyms (MPLS, 
> GMPLS, TE, LSP, ERO) - make sure they are expanded for their first 
> usage.
>
>
>
>  

ok, sections expanded, others shortened ... overall same length ;-)

> Section 2 states that an ERO expansion is either up to the next loose 
> hop or to the destination. But, in fact, the ERO expansion may also be 
> any partial fragment towards either of these targets (including next 
> hop resolution). I suggest re-wording this paragraph to list (as 
> bullets) what an ERO might contain, and in a separate list, what the 
> computation might produce.
>
>
>

We listed in this paragraph the most usual case of ERO expansion. If 
you're ok with this, elaborating further on ERO expansion is out of the 
scope of this document.

> In section 4.1 you add a note about the selection of component links 
> from within a bundle. While this is true, it is unclear why you pick 
> this case out but don't describe the selection of alternate resources 
> (e.g. lambdas). This is associated to the new error values defined in 
> section 4.2. How would you report a component link going oos? How 
> would you report a link resource (e.g. a lambda) going oos? If you use 
> "local link maintenance required" won't the computing node believe 
> that the whole link is unusable?

Indeed, this is why the node in charge of this link going oos should 
make the appropriate local decision on whether to report it, should an 
equivalent link not be found.

> If your answer here is that the recomputation will ignore the error 
> value and will perform a recomputation based on the new TED (see 
> [GR-SHUT]) then why do you need to distinguish between link 
> maintenance required and node maintenance required? If you actually 
> need to report the component link or resource as a separate quantity, 
> I suggest you refer to the crankback draft.
>
>
>
>  
> Section 4.1
>
>
>
> I'm not comfortable with the Session Attributes toggling like this. 
> This type of function is what the Admin Status object was invented 
> for.
>
>
>
>  
> Section 5.3.1
>
>
>
>    This
>
>
>
> This implies that a Path refresh *never* carries this bit set (which 
> makes it a trigger when it comes after a Path with the bit set).
>
>
>
> Thus we may lose the request (either through a lost Path message, or 
> through a refresh catching up with a trigger Path message). I think we 
> discussed this before. You need to make it clear in the draft that 
> these requests can be lost.
>
>
>
> I think it is also worth considering how to prevent the toggling off 
> of the bit from appearing as a trigger message.
>
>
>

Case of a lost path message: in order to cover this case, *the* 
solution consists of using reliable messaging as defined in RFC2961 
(note that any change in a Path message objects would indeed not be 
detected if the Path is lost, this applies to any other LSP attribute). 
Note also, that resending the same Path message N times (which is an 
option that we did investigate) would not really solved the issue since 
the Path message would be resent after a delay which is dependent of 
the refresh period (which can itself be very long). Then this causes 
race condition with the reoptimization timer running on the head-end 
LSR which may lead to undesirable conditions. Thus, a Path message may 
indeed be lost and the solution consists of using reliable messaging, 
should the operator consider the lost of such Path message be 
unacceptable. I will add some text there. thanks.

> What does "the TE database must be updated" mean? Are you saying that 
> the TED is now built from information flooded by the IGP *and* by 
> information fed back from signaling? If so (and I don't approve!) then 
> you must define what happens when you receive a new LSA for the 
> specific link that contradicts the information signaled. There is a 
> strong argument that says that *the* method we use for building the 
> TED is IGP flooding - if this mechanism doesn't provide you with the 
> information you need, then you should propose extensions to the IGP, 
> not hook the information onto signaling.
>
>
>

Let me sightly disagree here. I'm fine to not mention this since this 
may be implementation specific. That said, I do think that this is 
highly desirable (in combination with timer-based mechanism) so as to 
speed convergence. Typically, upon receiving a PathErr message it does 
make sense to first update your TED or the head-end will keep trying 
the same path until an LSA/LSP get received. In many networks, such 
optimization is definitely required to speed up the TE LSP rerouting. 
Note that such behavior is implemented in commercial product.

> OTOH it may be that all you mean is that the Session state should be 
> updated to indicate the link or node that is being shut down so that 
> later recomputation can avoid this link. In this case, I suggest you 
> refer to the CCAMP crankback draft.
>
>
>

Still such update may be beneficial to other TE LSP and is orthogonal 
to the use of crankback ?

> Yes. Good point, but doesn't the error code also need to change? 
> Otherwise it will appear that the border node is the node being taken 
> oos.
>
>
>

If you agree with this argument I would vote for keeping the same error 
code since this would not change the action taken by the head-end.

>  
> Section 5.3.3. suggests the use of a timer. You must, therefore, 
> suggest a default time value. I suspect that you want to suggest some 
> basic multiple of the path computation time or of the IGP refresh 
> period.
>
>

Right, good point. Default of 5s has been suggested (not really 
correlated to the path computation time or the IGP refresh period since 
it relates more to the number of LSPs and level of network "dynamicity" 
which includes a number of parameters).

>
>  
> Section 6
>
>
>
> Need to describe the processing by an LSR that does not understand the 
> new flag (rather than understand it but not support it). note that you 
> cannot define the behavior of legacy LSRs in this draft, so you must 
> reference behavior defined in some other document.
>
>
>

Unfortunately I do not think that RFC3209 specifies the behavior of a 
node receiving a SESSION ATTRIBUTE flag that it does not understand ... 
An implementation should then just ignore such flag if it does not 
understand it.

>  
> Section 7
>
>
>
> This technique has implications for the trust model between domains. 
> In particular, one domain may cause another to perform additional 
> (excess or unnecessary) work simply to ease its own task or for 
> malicious reasons. Similarly, a headend domain might choose to ignore 
> the requests for re-optimization issued by another domain. I think you 
> need to point out that the peering agreements between domains need to 
> include a definition of how this technique is supported.
>
>

Agree Adrian and this is in line with the Inter-area req doc. Will add 
some text:

"Furthermore, a head-end LSR may decide to ignore explicit notification 
coming from a mid-point residing in another domain. Similarly, an LSR 
may decide to ignore (or accept but up to a pre-defined rate) path 
re-evaluation requests originated by a head-end LSR of another domain. 
"

thanks.

>
> Question...
>
>
>
>  
>
>
>
>
>
> How does the process of unsolicited notification (of a potential 
> better path rather than of a link going oos) avoid thrashing races? As 
> a very simple example, consider the following n/w.
>
>
>
>  
> <-A1-> <--A0-> <-A2->
>
>
>
> A-----B       C-----D
>
>
>
>       |       |
>
>
>
>       |       |
>
>
>
> E-----F---G---H-----I
>
>
>
>  
> Set up two LSPs AI and ED using EROs {A,B(L),H(L),I} and 
> {E,F(L),C(L),D} producing paths ABFGHI and EFGHCD.
>
>
>
>  
> Now install a *low* bandwidth link BC capable of carrying either but 
> not both LSPs. Both B and F will notice that the LSPs entering A0 
> through them can be re-optimized and will report the fact to A and E 
> respectively.

note that if the link is a "low" bw link, it is unlikely that B and F 
will report a better path but yes that could happen depending on the 
IGP links costs indeed.

> Both A and E will attempt mb4b, but (of course) only one will succeed. 
> In a small network, this is not a big deal, but in a large network 
> with a lot of LSPs this is clearly a waste of processing and will 
> cause a degree of network thrash maybe only in the control plane, but 
> maybe in the data plane if a lower priority LSP is re-routed first. In 
> fact, this scenario can cause significant disruption in the data plane 
> as the re-routed LSP will be preempted and could have been 
> successfully left in its original place.
>
>

Indeed, but this is no different that any other reoptimization scenario 
in a single area. If for example, a link is restored within an area 
that could offer a potentially more optimal path to a large number of 
TE LSPs, there could be race conditions indeed. This is usually sorted 
out by using jittered reoptimization at the head-end.

>
>  
> It seems that a considerably sophisticated policy is required for any 
> domain, but particularly core domains like A0. In effect, the domain 
> needs to evaluate the new link by examining all LSPs in the system and 
> selecting which one(s) should be re-optimized. This type of processing 
> is non-trivial and uses information stores that are not generally 
> available (i.e. LSP maps).
>
>
>
>
>
>
>  
> Thus I would suggest removing the unsolicited notification of 
> reoptimization opportunities (while retaining the unsolicited 
> notification of links going oos) or requiring that the policy be 
> timer-based not event triggered.
>
>
>
>

We would definitely prefer to keep this mode. Implementation could just 
activate the function for *some* sensitive LSP + combined with with 
jittered reoptimization but such notification is desirable to quickly 
take advantage of a newly restored link.

NOTE that link dampening (IGP) can also be used here; this had been 
discussed in the FRR document.

Thanks for your comments !

JP.

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 29 Jan 2005 14:59:42 -0000

Thanks JP (and thanks for the rigour of tracking down all of the points raised).

[SNIPPED]

>path that contains at least one loose hop or a strict (abstract node) 

So, to be clear, you are only interested in the reoptimization of such "loosely routed LSPs".

But note RFC 3209...
   An abstract node
   is a group of nodes whose internal topology is opaque to the ingress
   node of the LSP.  An abstract node is said to be simple if it
   contains only one physical node.
So your definition is not quite accurate since a "strict (abstract node) hop" includes a strict simple abstract node.

How about:
   A loosely routed LSP is defined as one that does not contain a full
   explicit route identifying each LSR along the path of the LSP at 
   the time it is signaled by the ingress LSR. Such an LSP is signaled
   with no ERO, with an ERO that contains at least one loose hop, or
   with an ERO that contains an abstract node that is not a simple
   abstract node (that is, an abstract node that identifies more than
   one LSR).

>loose path also includes the case of a path where at least one hop is 

Following the above definition, that is true. Just check that the defintion appears early in the Introduction (and maybe in the Abstract).

>you're ok with this, elaborating further on ERO expansion is out of the 

"Most usual" is subjective. Consider nested domains.
But I'm not too bothered about this particular issue, so leave the text.
 
>> This type of function is what the Admin Status object was invented 

?

>optimization is definitely required to speed up the TE LSP rerouting. 

I really disagree (more than slightly :-)

It is absolutely OK to say that the failed/going-oos link/node can be supplied to the path computation component as an exclusion. This applies to the recomputation of the failed LSP.

It is very suspect to say that you will update the TED. This would apply to the computation of new LSP *only* by the LSR that happens to be the ingress for the failed LSP. How do you know that the next LSP computed will be computed at that LSR?

For this procedure to have any realistic meaning, you would want the information to reach all computation points, and the signaling protocol should not do this.

Certainly, if you cite "rapid convergence", we will have to convince the IGP WGs and the ADs that it is correct to distribute routing information using the signaling protocol, and not to make changes to the IGP as necessary.

Again, I would like to refer you to the crankback draft which handles this issue at ingress and transit computation points.

>to the use of crankback?

The only way in which it is orthogonal is that it has been specified differently.

We have three drafts we need to sort out here.
- Loose path reoptimization
- Crankback
- Graceful shutdown

It seems to me (humbly ;-) that crankback defines the mechanisms for reporting failed resources during LSP setup or after the LSP is established. It specifies the procedures by which various LSRs may attempt to reroute.

Graceful shutdown specifies procedures for withdrawing resources so that LSPs are moved using make-before-break before a resource is set oos. This uses existing routing and signaling procedures, but introduces new error codes so that we can distinguish graceful shutdown from failure cases.

Loose path reoptimization essentially defines how an ingress may request information about potential reoptimization, and how an LSR may report potential reoptimization. The former is, of course, new procedures. The latter is new error codes.

I think I recall that you agreed that the local maintenance stuff should move out of the Loose Path Reoptimization draft [did I make that up?] in which case, the discussion we are having applies only to the split between crankback and graceful shutdown.

>code since this would not change the action taken by the head-end.

Note that this debate needs to be split for reoptimization and graceful shutdown. [Increasingly I hope I did hear you say you would remove all graceful shutdown text from this draft!]
But absolutely it would...

    AS1     :    AS2  
            :
A---.....---B---D-------Z
         \  :\ /       /
          \ : E       /
           \:        / 
            C---..../
            :

Graceful shutdown...
Link BD wants to go out of service.
B needs to report this to A so that there is a make-before-break resignaling.
B substitutes its address in the PathErr.
A assumes B is not healthy and routes through C (very sub-optimal).
A should have resignaled through B and allowed B to route via E.

Reoptimization...
LSP is via E. Link BD comes up.
B needs to signal simply "reoptimize".
Since B will do the recomputation, the PathErr can safely carry its address.

>> new flag (rather than understand it but not support it). Note that you 

You are correct. This is one of the joys in our life. 

But since nothing is stated, there is a high risk that your new flag will be zeroed out by a transit LSR. Oh dear; does that mean that your extensions cannot be guaranteed to work unless the whole network is upgraded?

So you need to make some statement. (Or perhaps you'd like to write a BCP for 3209?)

>will report a better path but yes that could happen depending on the 

Well, Let us assume that all links are 10G except BC which is 9.8G. Let us assume that the LSPs are 5G each...

>out by using jittered reoptimization at the head-end.

Sure. In a single domain you can apply sensible and rational reoptimization centrally. This is relatively trivial and works well because:
- repotimization of one LSP at a time is bound to lead to 
  relatively poor results
- reoptimization is not time-critical
Note that it is very important that an operation like reoptimization should not lead to LSPs being dropped. 

[SNIP]

>take advantage of a newly restored link.

OK, that's interesting.
So I didn't see any descripition of processing rules for when 25:6 is received. I (flasely) assumed that the text for 25:7 and 25:8 applied, but clearly it doesn't. Perhaps you'd like to add some processing thoughts for 25:6?

Cheers,
Adrian