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

[dimitri papadimitriou <dpapadimitriou@psg.com>]

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:

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