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

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