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

From: "AISSAOUI Mustapha" <[email-masked]>
Date: Fri, 7 Nov 2008 12:14:32 -0600

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: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Loa Andersson
> Sent: Monday, October 20, 2008 5:52 PM
> To: [email-masked]
> 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:  [email-masked]
>                                            [email-masked] 
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
> 
_______________________________________________
mpls mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls

---

From: "AISSAOUI Mustapha" <[email-masked]>
Date: Fri, 7 Nov 2008 12:14:36 -0600

Dear all,
below are my comments on draft-ietf-mpls-soft-preemption-13.txt.

Regards,
Mustapha.

1) Section 4.2 
   Upon (soft) preemption, the preemting node MUST issue a PathErr
   message with the error code=34 ("Reroute") and a value=1 ("Reroute
   request soft preemption"), to be confirmed by IANA.  

MA> There are some paragraphs which still state the use of "Notify"
error code. 

2) Section 4.2
   Upon (soft) preemption, the preemting node MUST issue a PathErr
   message with the error code=34 ("Reroute") and a value=1 ("Reroute
   request soft preemption"), to be confirmed by IANA.  

MA> It seems to me that we should keep the RRO flag in addition to the
PathErr. In many networks I am familiar with, RSVP refresh reduction is
not enabled, and thus one cannot guarantee reliable delivery of the
PathErr.
The combination of PathErr and RRO flag in Resv is not new and has been
used in FRR Global Revertive procedures in RFC 4090 to guarantee the
head-end will be notified.
I am not suggesting we should generalize this. For example in TE
graceful shutdown, the operator can always issue another PathErr by
configuring the graceful shutdown option on the interface targeted for
maintenance. However in soft pre-emption, there is a timer running at
the pre-empting node and the LSP is at risk of being deleted if not
re-routed.

3) Section 4.2

   If the local
   request directs a reroute around the local node, the error value
   "Local node maintenance required" MUST be used and the local node
   MUST be indicated in the ERROR_SPEC object.

MA> What does this have to do with soft pre-emption?

4) Section 6.1

   When the MESSAGE-ID extensions defined in [RFC2961] are available,
   PathErr messages with error code "Notify" and a error value "Reroute
   request soft preemption" SHOULD be sent in reliable mode.

MA> I believe we should remove this statement. This has nothing to do
with complying to this draft. It is really an operator's option. In many
networks, RSVP refresh reduction is not enabled.

5) Section 6.1

   The preempting node SHOULD first preempt the numerically higher
   priority TE LSP(s) having their "Soft Preemption Desired" bit of the
   SESSION ATTRIBUTE object cleared (TE LSP considered as Hard
   Preemptable).

MA> This is trying to dictate a specific implementation of a pre-emption
selection algorithm. There is no valid reason why LSPs with the the flag
cleared must be the first target. The pre-empting node runs an algorithm
which will provide a list of best-fit LSPs to free the requested
bandwidth. We cannot dictate a preference between LSPs which have the
flag set and those which do not have it. 
This draft only should be concerned about what the pre-empting node
should do to notify the head-end node *once it selected* the LSPs
candidates for pre-emption. 

I suggest to rephrase it as follows:
"
   The preempting node SHOULD first preempt the numerically higher
   priority TE LSP(s). It is a matter of local policy whether to
distinguish
   within the same priority among LSPs with the "Soft Preemption
Desired" bit of the
   SESSION ATTRIBUTE object cleared and those with this bit set.
"

6) Section 6.2
   Once a new path has been computed, the soft preempted TE LSP is
   rerouted using the non traffic disruptive make-before-break
   procedure.

MA> It should be mentioned that the interface information received in
the PathErr message will be kept by the head-end node for a period of
time that is implementation specific. If make-before-break is not
successful at the end of this period, the information is discarded.
========================================================================
========

---

From: Lou Berger <[email-masked]>
Date: Thu, 13 Nov 2008 20:01:55 -0500

Mustapha,
         Thanks for the comments.  See in-line responses.

At 01:14 PM 11/7/2008, AISSAOUI Mustapha wrote:
>state.

which is a form of a response as is stated in the subsequent sentence.

>There is no such a thing as an explicit response to the reroute

while this is true, the paragraph defines what is meant by 
response.  So there is no technical issue.  You may not be happy with 
the phrasing, but that's an issue of style.

>    Reroute request timeouts are used when the the LSP must be removed

there's a bit of redundancy in the text, so don't mind eliminating 
the negative form.

>way to correlate a new Path message to the reroute request.

MBB is only SHOULD, so we need to cover the case where the ingress 
uses a modified ERO.

>Secondly,

yes, but it *may* so the text is valid.

>Path_State_Removed flag set.

I think you may have misread the text. It says use Path_State_Removed 
flag *iff* it's supported.  I see no reason to use a less efficient 
(i.e., more expensive) mechanism in the case it's supported.

Much thanks for the comments.

Lou

---

From: Lou Berger <[email-masked]>
Date: Wed, 19 Nov 2008 12:00:46 -0600

Nic,
         Thanks again for the comment.  The next rev of the draft 
will limit applicability to P2P LSPs and state P2MP is for further study.

Lou

At 11:40 AM 10/29/2008, Nic Neate wrote:
>Hi Lou, Dimitri, JP,
>
>draft-ietf-mpls-gmpls-lsp-reroute doesn't explicitly include or 
>exclude P2MP LSPs, but I think most of the function applies equally 
>to both P2P and P2MP.  I'd like to suggest a couple of tweaks for 
>explicit P2MP support.
>
>1.  Section 2.3 recommends that ingress nodes use make-before-break 
>for rerouting:
>
>    ... When an
>    alternate path is identified, a corresponding make-before-break LSP
>    SHOULD be initiated, and standard make-before-break procedures MUST
>    be followed.
>
>For P2MP LSPs, the PathErr will only apply to one sub-group (or a 
>subset of the S2L sub-LSPs in a sub-group).  It would therefore be 
>more efficient to use sub-group-based re-optimization (RFC 4875 
>section 14.2) rather than make-before-break.
>
>2.  Section 2.2 of your draft states that transit nodes MUST use 
>"standard local repair processing":
>
>    When the reroute request can be processed locally, standard local
>    repair processing MUST be followed.
>
>For P2MP LSPs, I think that means sub-group-based 
>re-optimization.  If you agree, it would be helpful to state it 
>explicitly.  If not, please could you clarify.
>
>Thanks,
>
>Nic
>
>From: [email-masked] [mailto:[email-masked]] On Behalf 
>Of Loa Andersson
>Sent: 20 October 2008 22:52
>To: [email-masked]
>Cc: Ross Callon; Cisco - David Ward
>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.
>
>Please send comments to the working group mailing-list or to the 
>working group co-chairs.
>
>/Loa
>
>--
>Loa Andersson
>

---

From: "AISSAOUI Mustapha" <[email-masked]>
Date: Wed, 19 Nov 2008 13:54:12 -0600

Lou,
it is very confusing to refer to a "response" to the reroute request
when there is no such a message in existing RSVP protocol and that this
document does not define a new one. 

As for the valid responses as defined in this document, here is the
paragraph from Section 2.1.1:
"
   Valid responses are a PathTear message or a trigger
   Path message with an ERO avoiding the resource that was indicated in
   the reroute request.
"

I do not believe you can use a Path message with an ERO that avoids the
resource as a "response" to the reroute request because the LSPid is
different. You really cannot tell the trigger for the Path message. Only
a PathTear from the headend for that LSPid or a state timeout will
cancel the timer. 

Regards,
Mustapha. 

> Behalf Of Lou Berger
> Sent: Thursday, November 13, 2008 8:02 PM
> To: AISSAOUI Mustapha
> Cc: [email-masked]
> Subject: Re: [mpls] last call on three mpls wg documents
> 
> Mustapha,
> response.  So there is no technical issue.  You may not be 
> happy with the phrasing, but that's an issue of style.
> 
> there's a bit of redundancy in the text, so don't mind 
> eliminating the negative form.
> 
> 
> >2) Section 2.1.1

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 19 Nov 2008 20:09:40 -0000

I think Lou may mean a "response to an event" rather than a "response 
message".

"reaction" may be almost a synonym.

A

---

From: Lou Berger <[email-masked]>
Date: Wed, 19 Nov 2008 15:14:00 -0600

See in-line responses.

>document does not define a new one.

Yes, per my last message, I understand you are not happy with the 
choice of words.  Please note that it says a "response" not a 
"response message".  I think this is proper usage of the word "response".

Lou

---

From: Lou Berger <[email-masked]>
Date: Wed, 19 Nov 2008 15:15:39 -0600

humm, did you perhaps consult: http://www.thefreedictionary.com/response ?

And, yes you are correct.

Thanks,
Lou

At 02:09 PM 11/19/2008, Adrian Farrel wrote:
>I think Lou may mean a "response to an event" rather than a 
>"response message".
>
>----- Original Message ----- From: "AISSAOUI Mustapha" 
><[email-masked]>

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 19 Nov 2008 20:20:10 -0000

> humm, did you perhaps consult: http://www.thefreedictionary.com/response ?

No need; English is my native tongue.

:-)'