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

[JP Vasseur <jvasseur@cisco.com>]

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:

> 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

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

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

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

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.

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