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

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

Hi Matthew,
I noticed you have issued three more versions of this draft but I have
not seen a response to my comments below.

Regards,
Mustapha. 

> -----Original Message-----
> From: mpls-bounces at ietf.org [mailto:mpls-bounces at ietf.org] On 
> Behalf Of AISSAOUI Mustapha
> Sent: Friday, November 07, 2008 1:15 PM
> To: mpls at ietf.org
> Subject: Re: [mpls] last call on three mpls wg documents
> 
> 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
>