Re: [mpls] last call on three mpls wg documents

["AISSAOUI Mustapha" <Mustapha.Aissaoui at alcatel-lucent.com>]

Dear all,
below are my comments on draft-ietf-mpls-gmpls-lsp-reroute-02.txt.

Regards,
Mustapha.

1) Section 2.1.1
   Reroute request timeouts are used to remove an LSP when there is no
   response to a reroute request.  Reroute request timeouts MUST NOT be
   used, when the LSP is not to be removed at the expiration of the
   Reroute request timeout period.  

MA> The timeout is not for expecting a response but for deleting the
state. There is no such a thing as an explicit response to the reroute
request. Even a PathTear received before the timeout does not mean it
was in response to the reroute request. There could have been another
condition which triggered it.
I believe the main point to convey in this paragraph is that a timeout
is required if state must be removed within a time limit. I propose to
rephrase this as follows:
"
   Reroute request timeouts are used when the the LSP must be removed
within a    
   finite time limit.  
" 

2) Section 2.1.1 
   When such LSP removal is desired and
   after initiating a reroute request, the initiating node MUST initiate
   a timeout during which it expects to receive a response to the
   reroute request.  Valid responses are a PathTear message or a trigger
   Path message with an ERO avoiding the resource that was indicated in
   the reroute request.  If either type of message is received, the
   timeout period MUST be canceled and no further action is needed.

MA> The PathTear or a refresh timeout are the only events that will
cancel the timer. I do not think we can use any other message to cancel
the timer as first of all the LSPid will be different and there is no
way to correlate a new Path message to the reroute request. Secondly,
the new path computed by the head-end node may not traverse this node.

3) Section 2.1.1
   Removal is indicated upstream via a PathErr message with
   the error code of "Service preempted".  The Path_State_Removed flag
   MUST be set if supported.  When the Path_State_Removed flag is not
   supported, a corresponding ResvTear MUST also be sent.

MA> I do not believe there needs to be a precedence in using these two
methods. Either of them should be used. I propose to change this to:
"
Removal SHOULD be indicated upstream via either a ResvTear or a PathErr
message with the error code of "Service preempted" and the
Path_State_Removed flag set.
"
========================================================================
========
> -----Original Message-----
> From: mpls-bounces at ietf.org [mailto:mpls-bounces at ietf.org] On 
> Behalf Of Loa Andersson
> Sent: Monday, October 20, 2008 5:52 PM
> To: mpls at ietf.org
> Cc: Ross Callon; David Ward
> Subject: [mpls] last call on three mpls wg documents
> 
> Working group,
> 
> the authors of
> 
> draft-ietf-mpls-gmpls-lsp-reroute-02.txt
> draft-ietf-mpls-soft-preemption-13.txt
> draft-ietf-mpls-3209-patherr-03.txt
> 
> has asked that we issue a working group last call on these 
> document as a group. This mail starts the wg last call.
> 
> There has gone quite an effort to align the three document 
> and to create a coherent structure.
> 
> The working group last call will end on Nov 7.
> 
> Please send comments to the working group mailing-list or to 
> the working group co-chairs.
> 
> /Loa
> 
> --
> Loa Andersson
> 
> Principal Networking Architect
> Acreo AB                           phone:  +46 8 632 77 14
> Isafjordsgatan 22                  mobile: +46 739 81 21 64
> Kista, Sweden                      email:  loa.andersson at acreo.se
>                                            loa at pi.nu 
> _______________________________________________
> mpls mailing list
> mpls at ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
> 
_______________________________________________
mpls mailing list
mpls at ietf.org
https://www.ietf.org/mailman/listinfo/mpls